2

My application is having issues accepting the handshake about half the time in my production environment. On my local machine and in my staging environment, which is the same as production, it works every time.

It is a .Net Core 2.1 app using aspnet-signalr/1.1.4

I am not configuring SignalR to use any specifics in my startup.s

app.UseSignalR(routes => { routes.MapHub<PortfolioHub>("/loadpagedetailsjob"); }); app.UseMvc(routes => { routes.MapRoute( name: "default", template: "{controller=Dashboard}/{action=Index}/{id?}"); }); 

my PortfolioHub is just a direct implementation of the Hub class

and in my page

var connection = new signalR.HubConnectionBuilder() .withUrl('/loadpagedetailsjob') .configureLogging(signalR.LogLevel.Information) .build(); connection.start().then(function () { connection.invoke("Subscribe"); }); 

enter image description here

It looks like it tries to negotiate web socket then long polling and both fail. But the requests return 200

enter image description here

Since it is only happening sometimes I am having issues resolving the issue. My only suspicion at this point is since my environment is in AWS behind a load balance that the negotiate requests are routed to different servers which might cause the issue?

Any help is appreciated.

5
  • 1
    Are sticky sessions enabled on your LB? Commented Mar 9, 2020 at 13:34
  • @ChristophLütjen no it looks like it is disabled. And I found that my Staging environment only has 1 task instance while prod has 2. I updated staging to 2 instances and the problem arose. Now I am not a DevOps person and don't have control over our AWS instance. Do you know of any negatives for using Sticky Sessions, as I am going to need to convince someone to turn it on. Commented Mar 9, 2020 at 13:51
  • @ChristophLütjen that was the issue, I got it changed in AWS and all is right again. Thanks! Commented Mar 9, 2020 at 13:59
  • 1
    In general, sticky sessions will simply ensure that one client will use the same server for all requests - works, no problems. But... in general it's "not nice" if the app requires users to stay on one instance. There will be problems when deploying new versions and when scaling the cluster. Commented Mar 9, 2020 at 14:13
  • @ChristophLütjen please add your resolution as answer since it worked to the OP. Commented Mar 9, 2020 at 14:16

1 Answer 1

2

SignalR requires that one connection is always handled by the same server. The typical solution is to configure the load balancer to use sticky sessions. With sticky sessions enabled, the load balancer will route requests of the same user to the same backend server.

https://learn.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-3.1

Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.