3

I want to use deployment slots for my Blazor server side application, but it stops working for the current users during the swap and they have to refresh the page.

I'm using an Azure SignalR Service for performance reasons, so it kinda makes sense, I imagine it like this:

enter image description here

Connections are held in memory and when I swap, obviously that is gone. At least without a SignalR Service. But shouldn't my SignalR Service keep SignalR connections (see red)? Did I set it up incorrectly?

I found others having similar problems (without using Blazor), but I'm not sure if these are viable with Blazor, especially because I just want to mitigate that 1-2 minute downtime for an update...

Automated reconnect SignalR client disconnected on Azure slots swap

Storing connections in an external storage. But manually handling connections is absurd effort? https://learn.microsoft.com/en-us/aspnet/signalr/overview/guide-to-the-api/mapping-users-to-connections

Update: See: https://www.youtube.com/watch?v=Vvjdqq8MB44&t=12m10s

enter image description here

It seems there is "Web traffic" going directly to the Blazor app. My guess: After a swap the "Web traffic" still goes to the previous instance, while SignalR traffic goes to the newly swapped in instance. That sounds like a problem.

But once again, I have no clue what "Web traffic" actually is or if that is the problem and if Azure offers a way to solve the issue, so a definitive answer would still be appreciated.

Heinzlmaen
  • 869
  • 10
  • 20
  • Ideally the application should be able to reconnect without the need for a refresh. If that is not working, check if there's ARR Affinity cookie and disable it. – Thiago Custodio Aug 05 '20 at 17:59
  • Did you find any solution to this problem? – Nick Jan 05 '21 at 23:17
  • No. Not using the swap feature is just so much more appealing than spending days digging into the SignalR protocol and tons of Azure doc that might ultimately lead to nothing.. It's not like I haven't wasted enough time already. – Heinzlmaen Jan 06 '21 at 10:51
  • @Heinzlmaen How do you handle updates to your app right now? Don't your users still lose connection on each update? – Mertus Jan 25 '21 at 10:16
  • @Mertus Exactly. I haven't improved the situation for the users at all, since I asked this question. – Heinzlmaen Jan 25 '21 at 10:47

1 Answers1

1

I don't think you have it setup incorrectly. I looked into doing a similar thing and had the same results.

The azure signalr service is basically acting as a proxy, when you switch slot the azure signalr server is losing its connection to the blazor server hub which holds the current state.

I don't think there is anyway around it, when you want to update your blazor server site every connected client will lose its connection because it's not possible to move the client 'states' over to the new slot/site.

What would be nice is the ability for azure to switch the new slot in once all old connections have disconnected, but I don't think we'll ever get that as it's a very specific blazor server requirement.

Wesley King
  • 21
  • 5
  • For non SignalR applications existing connections don't disappear. Why should a proxy loose its connections? Also your answer sounds like a lot of speculation. – Heinzlmaen Sep 04 '20 at 09:29
  • My answer is speculation - I was only offering it as food for thought. The azure signalr service connects exactly like a normal signalr connection. Signalr maintains a permanent connection to the server, when you swap slots, the connection is lost, as the server it was connected to is now no longer available. This is just a guest however. So the azure signalr service is irrelevant here. Its simple the way blazor server side has been setup. – Wesley King Sep 04 '20 at 12:46
  • The swapped out server does not disappear, it is still there 100% functional. It is merely the azure app service that no longer points there. Established connections don't care whether the app service points to A or B. That is the whole point of doing a swap, the users don't feel a thing, because their connections are not terminated. – Heinzlmaen Sep 07 '20 at 07:06
  • By server I'm referring to the azure app service. Which is in effect just an iis app pool. Signalr makes a connection to that iis app pool when you switch deployment slots you are taking that app pool offline. In normal scenarios users wouldn't notice anything because no permanent connection is made via http. The app pool is spun up ready so when the user moves to next page the new app pool is ready for the request. But blazor server doesnt work like that, again this is just my understanding of it. Which explains the issues I was having and your having – Wesley King Sep 08 '20 at 06:29
  • Your understanding of swap & slots is wrong. Look at the url of your slots, they are all working, even the slot that has been swapped out. You can connect to both slots at the same time. And that makes total sense, when you think about it: REST isn't the only connection, already established websockets imo don't break and they should still point to the swapped out slot. But we are not solving the issue with this discussion and both more or less clueless. But I edited my answer, I recommend taking a look at that video. Have a nice day. – Heinzlmaen Sep 08 '20 at 10:27
  • I didn't realise swaping slots leaving the other one still online, however if you read this https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots#what-happens-during-a-swap It says during a swap the source & target instances are restarted. Restarting an app pool will break the signalR connection. The Blazor server method works via storing the state of the client in memory. When the instance is restarted all of this information is lost. Therefore meaning the blazor server client cannot reconnect automatically and has to manually refresh the page. – Wesley King Sep 09 '20 at 10:44
  • Only the source slot is being restarted: "The target slot remains online while the source slot is being prepared and warmed up..." – Heinzlmaen Sep 09 '20 at 11:03
  • Yup missed that bit. Well then something isnt right – Wesley King Sep 09 '20 at 11:07
  • Actually though. Point 6 "Now that the source slot has the pre-swap app previously in the target slot, perform the same operation by applying all settings and restarting the instances.". That sounds like when the swap has happened the what was target slot, is now in the source slot, is then restarted. So technically the target slot does always remain online, as the what was source was pre-warmed, then switched via routing so target slot never went down. But was your production slot is moved into staging slot it gets restarted with the setting for staging. – Wesley King Sep 09 '20 at 11:12
  • I think you're mixing the terminology, there is no "what was source slot", source = "what was STAGING", target = "what was PROD". See: https://stackoverflow.com/questions/56258043/are-the-live-connections-dropped-on-azure-while-doing-blue-green-deployment – Heinzlmaen Sep 09 '20 at 11:25
  • What does point 6 refer to then? what is being restarted? Actually i just read it again. It says the source slot has the "pre-swap app" which was your app that had all the signalr connections. That is then restarted – Wesley King Sep 09 '20 at 11:27