It's worth enumerating the different session setups that are in play and proposed so that we can understand a) what we need to do for jetty-9.4 to support existing (compat) session management and b) what we need to do for new jetty-runtime 9.4 session management options.

For jetty-runtime we want to introduce full-featured session management, whilst for compat-runtime we need to be 100% backwards compatible with session data format, and as backwards-compatible as possible in terms of functionality: in other words the initial aim is to be "bug-for-bug" compatible with the current compat-runtime session management. Future iterations may introduce more advanced session features in order to provide enhanced behaviour/fixes for existing bugs in compat session management.

I'm currently working on porting the legacy gcloud datastore sessions (described below) to jetty-9.4, and will next work on porting the no-op sessions.

no-op sessions

Used in compat when the user does not explicitly enable sessions in appengine-web.xml.
Characteristics:

bare minimum session functionality for jsps to work
no session-sharing for simultaneous requests
no caching
no persistence
no expiry
no scavenging

legacy gcloud datastore sessions

Used in compat when sessions-enabled=true in appengine-web.xml.
Characteristics:

single context only
no session-sharing for simultaneous requests
sessions persisted as soon as created
gcloud datastore persistence fronted by memcached for performance/help with non-sticky load-balancing
session scavenging by periodic hit to SessionServlet which deletes expired sessions without calling HttpSessionListeners
changes to session.maxIdleTime not persisted
need to maintain backwards compatibility with existing persisted session data format

non-clustered sessions

New feature for jetty-runtime.
Characteristics:

enabled by default
uses a standard jetty session module
sessions not clustered/persisted
sessions cached on local node only
characteristics of session caching very configurable eg when/if to evict sessions
only works with single node
session scavenging by thread in jetty runtime

clustered gcloud datastore sessions

New feature for jetty-runtime.
Characteristics:

uses a standard jetty session module
no compatibility with compat session data required
no session-sharing/caching
session scavenging by thread in jetty runtime

Issues:

how to enable gcloud session module from environment variable
how to allow user to configure session setup such as datastore backoff and retries and frequency of scavenging, see Jetty module activation #50.

clustered gcloud datastore sessions with memcached

New feature for jetty-runtime.
Characteristics:

as above, with memcached added as L2 cache for session data (also as standard jetty module)
Issues: same as above

Session Management backed by Datastore #41

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions