Centralised session info to remove dependency of stickiness!
See original GitHub issueYou want to:
- report a bug/enhancement
Current behaviour
When node clusters are used, it is required to maintain stickiness explicitly even though shared adapter is used socket.io-redis
. When client sends multiple requests, if subsequent requests doesn’t go to the same node worker where initial request was made, socket.io throws an error: Session ID unknown. How about caching this session information in a centralised place (May be in a redis
adapter itself) and make it work from any worker ?
Currently there are implementations available to make connections go to the same worker based of Client’s IP Address hashing. But these have to be managed explicitly and also might not help load balancing when users share common IP address. (Ex: An internal app being used within a same network).
Issue Analytics
- State:
- Created 6 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Sticky sessions for your Application Load Balancer
If a cookie expires, the session is no longer sticky and the client should remove the cookie from its cookie store. An HTTP/HTTPS...
Read more >Configuring sticky session attribute name - JBoss.org
Hi, is it possible to configure the sticky session attribute name? I need to use a name different to JSESSIONID. Ive tried: ProxyPass...
Read more >Using Replicated Cache vs LB sticky session - Stack Overflow
In such a scenario is it better to use a replicated/distributed cache like EhCache Or to use session stickiness of LB. If the...
Read more >Implementing Sticky Session Through Load Balancing - 华为云
Session persistence is one of the most common while complex problems in load balancing.Session persistence is also called sticky sessions.
Read more >What is Session Stickiness | Pros and Cons of Using ... - Imperva
With sticky sessions, a load balancer assigns an identifying attribute to a user, typically by issuing a cookie or by tracking their IP...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I am also working through this problem and would prefer not to use sticky sessions. I am curious to know what the synchronization issues were pre 1.0.x that led to the deprecation of shared session support?
For future readers:
We have added some explanation here: https://socket.io/docs/v4/using-multiple-nodes/#Why-is-sticky-session-required
Within a Node.js cluster, you can now use the cluster adapter and the
@socket.io/sticky
package:Documentation:
Please reopen if needed.