This repository was archived by the owner on Sep 16, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 16, 2021. It is now read-only.
Enable session clustering in jetty9 non compat. was: Copying session variables between different instances is broken #183
Description
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
Activity
lesv commentedon Feb 25, 2016
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 commentedon Feb 25, 2016
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:
lesv commentedon Feb 25, 2016
Sorry - Yes - this is for non-compat - and yes - we are seeking advice for how to handle this in userland.
ludoch commentedon Feb 25, 2016
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:
lesv commentedon Feb 25, 2016
Your responses all require configuration that can't be set by our users, if we could use that stuff, we would.
ludoch commentedon Feb 25, 2016
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:
ludoch commentedon Feb 25, 2016
Extra config might be able to define as xml files in your app. Will check with the Jetty folks.
lesv commentedon Feb 25, 2016
There is an issue for using Memcache & Cloud Datastore.
An Extra config to enable these things would be a win.
lesv commentedon Feb 25, 2016
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 commentedon Feb 26, 2016
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 commentedon Feb 26, 2016
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 commentedon Feb 26, 2016
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.
lesv commentedon Feb 26, 2016
Cool - @ludoch should decide on direction.
For now, I've asked @shun-fan to do login and Session handling as Filters (We are working on a Getting Started sample and documentation) and we can change that once things change.
As for the Datastore plugin, unless you've rev'd it recently, I suspect it's not based on the correct API set. (https://github.com/GoogleCloudPlatform/gcloud-java)
I'm not sure if extending the image is easiest approach for our users. It tends to get messy and difficult to maintain. (I've done it a few times).
janbartel commentedon Feb 27, 2016
@lesv looks like gcloud-java is up to rev 0.1.4. Jetty is at 0.0.8. On a quick compile attempt, looks like there is some incompatibility in the api. I'll work on updating to 0.1.4. I'll see if I can get it into a jetty 9.3.8.RC1 release or not (we just did RC0).
gregw commentedon Feb 27, 2016
@lesv I'm a bit unsure how applications are going to deployed on this image (the non -compat Jetty9 image). I thought creating a new image in the normal docker way was the intended path to use this image! Is there another path that does need a new image? If so, can you point me to it?
light bulb moment Is it just a normal gcloud:deploy but in a non-compat mode?
If so, then perhaps we should come up with a simple way for such deployments to activate additional jetty modules and to add either properties and/or XML configuration?
We should also provide and example app for this (or is there one already?)
lesv commentedon Feb 28, 2016
Yep - it's a normal "mvn gcloud:deploy" -- hence my grumpiness at Ludo
earlier. What ever turns it on should be easy to do.
On Sat, Feb 27, 2016 at 9:54 AM, Greg Wilkins notifications@github.com
wrote:
lesv commentedon Feb 28, 2016
I should point out that it is both mvn gcloud:deploy and mvn jetty:run (running locally) that we promote. Ideally we should find a solution that can work in both cases.
gregw commentedon Feb 29, 2016
@lesv Ah I'm understanding the scenario now. I had not realised the jetty9 image was intended for use by the SDK for apps that do not need to compat level.
Having discussed this with @janbartel, we have a little bit of a challenge to make this nice. The jetty-maven-plugin predates the module system used by jetty's start.jar, thus to configure the server for jetty:run you pass it custom XML. To configure the server for a gcloud:deploy, it would be best to pass it a list of modules & parameters (and only custom XML for very special config).
So I think module/param based configuration is a good feature to add to jetty:run, but I will defer to @janbartel if that can be done in the 9.3.x or will it need a bit more drastic re factoring of our distribution artefacts in 9.4.x so that the modules can be made available to the plugin.
Meanwhile, we will have a look at how we can best pass modules and configuration for a gcloud:deploy usage. Do you (@lesv ) have an example app we can look at? Is it just that you use a Dockerfile that names the instance or is there something in the appengine-web.xml ?
lesv commentedon Feb 29, 2016
@gregw @janbartel The way we document your work is:
https://cloud.google.com/appengine/docs/managed-vms/java/hello-world
Pure Jetty: https://cloud.google.com/appengine/docs/managed-vms/java/dev-jetty9
Compat: https://cloud.google.com/appengine/docs/managed-vms/java/dev-jetty9-and-apis
The code that @shun-fan is working on: https://github.com/GoogleCloudPlatform/getting-started-java/tree/master/bookshelf
[-]Copying session variables between different instances is broken[/-][+]Enable session clustering in jetty9 non compat. was: Copying session variables between different instances is broken[/+]janbartel commentedon Apr 27, 2016
Just want to document that I've begun the IP clearance process at Eclipse to allow jetty to update to gcloud-datastore version 0.2.0.
gregw commentedon Apr 27, 2016
An example non compat session clustering example has been prepared at GoogleCloudPlatform/java-docs-samples#123, but some more work is needed
gregw commentedon Apr 28, 2016
Closing as a duplicate of #167