Skip to content
This repository was archived by the owner on Sep 16, 2021. It is now read-only.
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

Closed

Description

@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.

Activity

  1. ludoch commented on Feb 3, 2016

    @ludoch
    Contributor

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

  2. lesv commented on Feb 3, 2016

    @lesv
    Author

    Yep - I'd like something for Jetty9

  3. lesv commented on Feb 3, 2016

    @lesv
    Author

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

  4. ludoch commented on Feb 3, 2016

    @ludoch
    Contributor

    So non compat, right?

    On Wed, Feb 3, 2016 at 2:33 PM, Les Vogel notifications@github.com wrote:

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

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

  5. lesv commented on Feb 3, 2016

    @lesv
    Author

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

  6. gregw commented on Feb 4, 2016

    @gregw
    Contributor

    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.

  7. assigned and unassigned on Feb 4, 2016
  8. ludoch commented on Feb 4, 2016

    @ludoch
    Contributor

    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:

    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)
    .

  9. lesv commented on Feb 4, 2016

    @lesv
    Author

    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.

  10. janbartel commented on Feb 5, 2016

    @janbartel
    Contributor

    @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

  11. aozarov commented on Apr 27, 2016

    @aozarov
    Contributor
  12. gregw commented on Apr 28, 2016

    @gregw
    Contributor

    #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

  13. gregw commented on Sep 8, 2016

    @gregw
    Contributor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions