GCloudSessionManager doesn't appear to be enabled in non-compat runtimes...

[lesv]

A quick search of the repo, and I notice that gcloudSession isn't used, nor the GCloudSessionIdManager as described in Chapter 10.

Would really be good if we had a way to preserve sessions if a user needed it.

[ludoch]

Where would you want it? compat or jetty9?
For compat, we already have a session manager.

[lesv]

Yep - I'd like something for Jetty9

[lesv]

Datastore, Memecache, Cloud Bigtable (in an ideal world)

[ludoch]

So non compat, right?

On Wed, Feb 3, 2016 at 2:33 PM, Les Vogel [email protected] wrote:

Datastore, Memecache, Cloud Bigtable (in an ideal world)

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

[lesv]

Yep -- I think we should at least offer sessions -- it's way too hard for users to modify Jetty to roll their own.

[gregw]

in the current release (9.3.7) we have a simple gcloud session manager. The next major release (9.4.x) will have the new session manager that @janbartel has been working on that will allow memecache and datastore to be used together (and should probably replace the one in compat also).

So we can activate the simple one for now. However, we need to work out how that will work if the image is run on a local docker for testing etc. should we inject an appkey for the datastore and use it remotely or should we just run the hashsession manager....??? Will assign to jan to work out the details.

[ludoch]

Let's treat it as low priority for now. Compat can be used if a customer
wants session OOB.
In 9.4.x, I would suggest we do a sample on how to enable it in the jetty
image, but it should not be on by default.

On Wed, Feb 3, 2016 at 9:56 PM, Greg Wilkins [email protected]
wrote:

in the current release (9.3.7) we have a simple gcloud session manager.
The next major release (9.4.x) will have the new session manager that
@janbartel https://github.com/janbartel has been working on that will
allow memecache and datastore to be used together (and should probably
replace the one in compat also).

So we can activate the simple one for now. However, we need to work out
how that will work if the image is run on a local docker for testing etc.
should we inject an appkey for the datastore and use it remotely or should
we just run the hashsession manager....??? Will assign to jan to work out
the details.

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

[lesv]

What I would like is that it enables by env vars. If I give you enough info to do it, it happens, otherwise, it doesn't.

[janbartel]

@lesv the jetty GCloudSessionManager in jetty-9.3.x should certainly be able to be activated. We'd have to do some swizzling of env vars into jetty properties (for properties see list in http://www.eclipse.org/jetty/documentation/current/session-clustering-gcloud-datastore.html) for contacting a remote gcloud store. Env vars are already used for contacting a local dev gcloud server. One configuration issue we would have to consider is how to obtain a unique nodeid for each jetty server enabled for gcloud sessions. Whilst the gcloud session config properties would be invariant for each deployment, each deployment would need its own unique nodeId. I'll check with @gregw if there is anything we could use for that already in place.

One difference between the jetty gcloud session manager and the compat one - as @gregw mentioned - is that the gcloud session manager does NOT use memcache as a write-through cache for sessions in the way that the compat session manager does. In the 9.3.x version, sessions are retained in memory, and written through to the gcloud store when a request exists iff there have been changes to session data.

One advantage of the jetty gcloud session manager over the compat one is that multiple concurrent requests for the same session id will automatically use the same session object. In the compat one, each request will obtain a new session instance leading to unpredictable outcomes when session data is written.

Also as @gregw mentioned, we're working on a new session manager architecture for jetty-9.4 where using memcache as a cache in front of gcloud datastore will be possible, as will adding in other features such as passivating out to gcloud in-memory sessions that have been idle for a configurable amount of time.

Jan

[aozarov]

/cc @aozarov

[gregw]

#183 has been closed as a duplicate of this issue. #188 had also had become a duplicate, so has been closed.

An example non compat session clustering example has been prepared at GoogleCloudPlatform/java-docs-samples#123, but some more work is needed

[gregw]

obsoleted by GoogleCloudPlatform/jetty-runtime#5