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

Distributed sessions #8125

Closed
rymsha opened this issue Jun 3, 2020 · 3 comments
Closed

Distributed sessions #8125

rymsha opened this issue Jun 3, 2020 · 3 comments
Assignees
Labels
Milestone

Comments

@rymsha
Copy link
Contributor

rymsha commented Jun 3, 2020

Thanks to Hazelcast jetty sessions can be distributed.

Need to cover a few use cases:

  • no sticky sessions configured
  • sticky sessions configured on /
  • sticky sessions configured on specific path (i.e. /admin)
@rymsha rymsha added the Feature label Jun 3, 2020
@rymsha rymsha self-assigned this Jun 3, 2020
@rymsha rymsha changed the title Distributed sessions usecases Distributed sessions use-cases Jun 4, 2020
rymsha added a commit that referenced this issue Jun 4, 2020
@rymsha
Copy link
Contributor Author

rymsha commented Jun 4, 2020

Hazelcast distributed sessions are enabled by storeMode = replicated parameter in com.enonic.xp.web.sessionstore.cfg
In this mode all sessions are available on all XP nodes where storeMode = replicated is enabled.

  • It mitigates problem of lost sessions when one node is restarted (because persistent sessions gracefully migrate to other nodes)
  • It also mitigates problem of lost sessions when one node is crashed (because persistent sessions have replicas)
  • it simplifies load-distribution over nodes (in some cases)

LB sticky sessions are turned off:
In order to work correctly sessions must be persisted as soon as they get created and as soon as they are responded:

saveOnCreate = true
flushOnResponseCommit = true

LB sticky sessions are turned on on root context (/):

For performance reasons it may be good idea to minimize session persistence (this is default setting)

saveOnCreate = false
flushOnResponseCommit = false

However any long living request (i.e. long-polling, SSE, websocket?) within a session may not allow session to be persisted and session may be lost when session-initiating server crashes.

LB sticky sessions are turned on on specific path (i.e. /admin):

Is currently not recommended, because XP supports session cookie only on root path. Session cookie can then be created when user visits /admin pages, and stay with user even while she visits other paths.

Anyway to work properly persistence settings should be same as in case of sticky sessions turned off.

saveOnCreate = true
flushOnResponseCommit = true

For configurations without long living requests it may be sufficient to persist sessions only on create

saveOnCreate = true
flushOnResponseCommit = false

@sigdestad
Copy link
Member

How does this relate to enabing Hazelcast + controlling which nodes may hold the actual distributed data (aka data=true)

@rymsha
Copy link
Contributor Author

rymsha commented Jun 4, 2020

It doesn't. Why?

rymsha added a commit that referenced this issue Jun 5, 2020
@rymsha rymsha mentioned this issue Jun 10, 2020
rymsha added a commit that referenced this issue Jun 16, 2020
@alansemenov alansemenov changed the title Distributed sessions use-cases Distributed sessions Jun 23, 2020
@rymsha rymsha added this to the 7.4.0 milestone Jul 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants