server: GraphQL Subscription does not close sockets to Load Balancer

Hello Group,

Great work with V5.0. Lots of great improvements.

Having an issue with the latest WebSockets (Subscriptions). Prior to V5, #255 was an on-going issue, where we would get these constant disconnects in an aborted status. This is now gone. However, I have noticed that when behind a load balancer we have some major issues with sockets not being closed on the .Net side.

image

This is my server running for just a few minutes, as you can see 4,600~ connections are open. We currently have about 40 people on the site, thus, its not possible. How did it get so high? Watch. Now, what I will do is force my load balancer to crash, if we did have 4,600 connections, and if .net releases the connections, we would see it drop to ~0.

image

Here is what we get, the existing connections stay open, and an additional ~300 connections are created. Meaning that the connection is not being closed on the .Net side when there is no way the connection can still be open as I crashed the load balancer.

I can see my DevTools is working correctly to the site (React) is re-creating the connection after the failure of a socket (Reboot).

image

(Yes, I rebooted many times, which is why the socket closes). Also, If no traffic is sent for 60 seconds, the connection is closed via the load balancer. This is configurable from the load balancer side. Since the .Net side is not closing the socket, eventually the server crashes with 503.2 Too many connections.

Any assistance in a quick resolution would be awesome otherwise, I have to downgrade back to V3.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 39 (22 by maintainers)

Most upvoted comments

Once a solution is found, we should ensure that it works correctly whether the connection is gracefully terminated from the server side or the client side, or if the client connection is unexpectedly lost (i.e. no TCP FIN packet received by the server).