Enable session clustering in jetty9 non compat. was: Copying session variables between different instances is broken

[johnshunfan]

Currently, session variables stored in MVM instance are not copied over to the other instances. Will this ever be done automatically in the runtime? What are best practices for manually copying session variables around? I was considering generating an ID using secure random and storing it in a cookie, then using the ID as a key for datastore entities storing session variables.
@lesv

[lesv]

An alternative phrasing of this might be: JSESSIONID is unique within an instance, but when you have multiple instances -- you appear to get a new JSESSIONID, what is the best practice for dealing with state for the non-compat runtimes as currently configured?

[ludoch]

This is for non compat, right?

Please be specific. If this is for non compat, it seems that this is in
userland to find the best option.

On Thu, Feb 25, 2016 at 11:56 AM, Les Vogel notifications@github.com
wrote:

An alternative phrasing of this might be: JSESSIONID is unique within an
instance, but when you have multiple instances -- you appear to get a new
JSESSIONID, what is the best practice for dealing with state for the
non-compat runtimes as currently configured?

—
Reply to this email directly or view it on GitHub
#183 (comment)
.

[lesv]

Sorry - Yes - this is for non-compat - and yes - we are seeking advice for how to handle this in userland.

[ludoch]

https://www.eclipse.org/jetty/documentation/current/session-clustering-gcloud-datastore.html
or
https://www.eclipse.org/jetty/documentation/current/session-clustering-infinispan.html
or
https://www.eclipse.org/jetty/documentation/current/session-clustering-mongodb.html
or
https://www.eclipse.org/jetty/documentation/current/session-clustering-jdbc.html
or many other possible solutions

On Thu, Feb 25, 2016 at 1:03 PM, Les Vogel notifications@github.com wrote:

Sorry - Yes - this is for non-compat - and yes - we are seeking advice for
how to handle this in userland.

—
Reply to this email directly or view it on GitHub
#183 (comment)
.

[lesv]

Your responses all require configuration that can't be set by our users, if we could use that stuff, we would.

[ludoch]

Maybe we should add an option for the cloud datastore?

On Thu, Feb 25, 2016 at 1:12 PM, Les Vogel notifications@github.com wrote:

Your responses all require configuration that can't be set by our users,
if we could use that stuff, we would.

—
Reply to this email directly or view it on GitHub
#183 (comment)
.

[ludoch]

Extra config might be able to define as xml files in your app. Will check with the Jetty folks.

[lesv]

There is an issue for using Memcache & Cloud Datastore.

An Extra config to enable these things would be a win.

[lesv]

We are trying to do the right thing w/ Jetty, w/o the proper configuration files being enabled. The alternative is something like https://github.com/hazelcast/hazelcast-wm/blob/master/src/main/java/com/hazelcast/web/WebFilter.java (adjusted for our environment)

[gregw]

How about we start by adding an example to the java-docs-samples repository of how to extend this image with configuration for a different session manager (gcloud data store would be the obvious choice).

Once we all look at that , we can see how difficult and/or easy it is and then decide if we need to move a parameterised version of it into the base image.

Note that we will not have full memecache+datastore support until we go to 9.4 and the new session manager that @janbartel has been developing.

[gregw]

as a secondary approach, @janbartel is investigating if the session managers can be entirely configured from within a WEB-INF/jetty-web.xml file, which would allow it all to be within the application... but as that still requires a new image / Dockerfile it may just be simplest to configure normally following the example(s) we develop.

[janbartel]

I've investigated the approach that @gregw mentioned of putting all jars and config into the webapp, and it is not particularly easy to make work. If it was absolutely essential, it could be done, but the cleanest approach is probably the one @gregw first suggested of documenting how to extend the docker image to include a session manager.