You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
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.
GCloudSessionManager doesn't appear to be enabled in non-compat runtimes... #167
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.
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.
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 @janbartelhttps://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 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.
Activity
ludoch commentedon Feb 3, 2016
Where would you want it? compat or jetty9?
For compat, we already have a session manager.
lesv commentedon Feb 3, 2016
Yep - I'd like something for Jetty9
lesv commentedon Feb 3, 2016
Datastore, Memecache, Cloud Bigtable (in an ideal world)
ludoch commentedon Feb 3, 2016
So non compat, right?
On Wed, Feb 3, 2016 at 2:33 PM, Les Vogel notifications@github.com wrote:
lesv commentedon Feb 3, 2016
Yep -- I think we should at least offer sessions -- it's way too hard for users to modify Jetty to roll their own.
gregw commentedon Feb 4, 2016
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 commentedon Feb 4, 2016
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 notifications@github.com
wrote:
lesv commentedon Feb 4, 2016
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 commentedon Feb 5, 2016
@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 commentedon Apr 27, 2016
/cc @aozarov
gregw commentedon Apr 28, 2016
#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 commentedon Sep 8, 2016
obsoleted by GoogleCloudPlatform/jetty-runtime#5