Last post Mar 24, 2021 10:14 PM by verbedr
Mar 15, 2021 12:06 PM|verbedr|LINK
Whenever I deploy to a slot and do an (auto) slot swap. The Signalr service is still connecting to the old production slot after the swap for some clients. Is there something we overlooked?
We do have client ID that we reuse (client ID is the ID of the authenticated user) but how can this happen even when we restarted the SignalR service? Is there a way to see have a list of backend servers connecting to that SignalR service?
Mar 22, 2021 10:36 PM|bruce (sqlwork.com)|LINK
you are probably using affinity, so the client stays connected to the old slot. where the context is, otherwise why use affinity.
Mar 24, 2021 10:14 PM|verbedr|LINK
Yes we are using ARR Affinity but the calls to new the new API are working. It is only the hub which is failing due to new methods. Further more instance ID's and thus the value of the cookie do not change when using slot deployment. I guess that slots routing
is done after ARR selection and every instance will have its slots.
Perhaps it is the backplane connection from SignalR Service to the web application that is using a different technology and keeps connections open for a longer time. But then again after deployment the clients do reconnect to the API. And thus a new connection
ID is created. The only thing I can come up with is that the ClientId which remains the same for every user is linked to a server internally.
Anyway your remark made me think why we are still using this ARR Affinity. I think we will remove it anyway as it serves no purpose any more.