Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Session Affinity / sticky sessions using Cookies #390

Open
aersam opened this issue Aug 27, 2024 · 2 comments
Open

Session Affinity / sticky sessions using Cookies #390

aersam opened this issue Aug 27, 2024 · 2 comments
Labels
wontfix This will not be worked on

Comments

@aersam
Copy link

aersam commented Aug 27, 2024

Many Python tools use some state per user in simple python dict's or similar. This makes it impossible to use multiple processes and so it scales not this good. For example, see: https://github.com/zauberzeug/nicegui/wiki/FAQs#how-to-avoid-the-reloading-because-handshake-failed-javascript-error-message-which-results-in-a-full-page-reload

It would be so great for granian to support some kind of session affinity, so that a cookie with some value would cause granian to send a request to always the same process. so an app could make the user stick on the same process (as long as it's not restarted).

It's a feature usually only supported on more complex load balancers, gunicorn does not support it. But as it's really a common problem in python, it would be so great for granian to support it.

@gi0baro
Copy link
Member

gi0baro commented Aug 27, 2024

I might understand the frustration, but at the same time if you need that scale level you shouldn't really keep the state into a Python dictionary or whatever struct in the process memory IMHO.

Granian might be written in Rust, but it still submit to Python rules, given that's where the application code actually lands.
Plus, granian is structured in a way there's no such thing as a "main controller", all the workers behave the same, and the listen socket is just shared across them. In order to provide what you ask, requests should be firstly parsed into some "main process" and then forwarded to the relevant "slave process", architecture which will for sure add latency and decrease the today performance.

Given that both the use case sounds quite an edge case to me, and that the balancing theme is quite out of scope for the project, I hardly doubt this will be ever done.

@gi0baro gi0baro added the wontfix This will not be worked on label Aug 27, 2024
@jules-ch
Copy link

jules-ch commented Sep 8, 2024

You can enable this behaviour on the reverse proxy or load balancer side.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

3 participants