Issue #1793
This commit is contained in:
Jan Bartel
parent
d8e035ba0d
commit
df0e6d7f43
|
|
@ -25,6 +25,8 @@ Jetty also offers more niche session managers that leverage backends such as Mon
|
|||
|
||||
include::session-hierarchy.adoc[]
|
||||
include::sessions-details.adoc[]
|
||||
include::session-configuration-housekeeper.adoc[]
|
||||
include::session-configuration-sessioncache.adoc[]
|
||||
include::session-configuration-memory.adoc[]
|
||||
include::session-configuration-file-system.adoc[]
|
||||
include::session-configuration-jdbc.adoc[]
|
||||
|
|
@ -32,6 +34,8 @@ include::session-configuration-mongodb.adoc[]
|
|||
include::session-configuration-infinispan.adoc[]
|
||||
include::session-configuration-hazelcast.adoc[]
|
||||
include::session-configuration-gcloud.adoc[]
|
||||
include::session-configuration-memcachedsessiondatastore.adoc[]
|
||||
include::sessions-usecases.adoc[]
|
||||
//include::setting-session-characteristics.adoc[]
|
||||
//include::using-persistent-sessions.adoc[]
|
||||
//include::session-clustering-jdbc.adoc[]
|
||||
|
|
|
|||
|
|
@ -16,7 +16,9 @@
|
|||
|
||||
[[configuring-sessions-file-system]]
|
||||
|
||||
=== Non-Clustered Session Management: File System
|
||||
=== Persisted Sessions: File System
|
||||
|
||||
Note: Persisting sessions to the local file system should NOT be used in a clustered environment.
|
||||
|
||||
==== Enabling File System Sessions
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@
|
|||
// ========================================================================
|
||||
|
||||
[[configuring-sessions-gcloud]]
|
||||
=== Clustered Session Management: Google Cloud DataStore
|
||||
=== Persisted Sessions: Google Cloud DataStore
|
||||
|
||||
==== Preparation
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
[[configuring-sessions-hazelcast]]
|
||||
|
||||
=== Clustered Session Management: Hazelcast
|
||||
=== Persisted Sessions: Hazelcast
|
||||
|
||||
==== Enabling Hazelcast Sessions
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,53 @@
|
|||
// ========================================================================
|
||||
// Copyright (c) 1995-2017 Mort Bay Consulting Pty. Ltd.
|
||||
// ========================================================================
|
||||
// All rights reserved. This program and the accompanying materials
|
||||
// are made available under the terms of the Eclipse Public License v1.0
|
||||
// and Apache License v2.0 which accompanies this distribution.
|
||||
//
|
||||
// The Eclipse Public License is available at
|
||||
// http://www.eclipse.org/legal/epl-v10.html
|
||||
//
|
||||
// The Apache License v2.0 is available at
|
||||
// http://www.opensource.org/licenses/apache2.0.php
|
||||
//
|
||||
// You may elect to redistribute this code under either of these licenses.
|
||||
// ========================================================================
|
||||
|
||||
[[session-configuration-housekeeper]]
|
||||
=== The SessionIdManager and the Housekeeper
|
||||
|
||||
==== The Defaults
|
||||
By default, jetty will instantiate a single instance of the DefaultSessionIdManager and HouseKeeper at startup with default settings.
|
||||
|
||||
The default settings are:
|
||||
|
||||
DefaultSessionIdManager: worker name::
|
||||
This uniquely identifies the jetty server instance within a cluster.
|
||||
It is set from the value of the JETTY_WORKER_INSTANCE environment variable, or "node0" if the environment value is not set.
|
||||
If you have more than one jetty instance, it is crucial that you explicitly configure the worker name on each jetty instance (see below for how to configure).
|
||||
|
||||
HouseKeeper: scavenge interval::
|
||||
This is the period in seconds between runs of the session scavenger, and by default is set to the equivalent of 10mins.
|
||||
As a rule of thumb, you should ensure that the scavenge interval is shorter than the maxInactiveInterval of your sessions to ensure that they are promptly scavenged. See below for instructions on how to configure this.
|
||||
|
||||
==== Configuring
|
||||
To change the default values, use the link:#startup-modules[module system] to link:#startup-modules[enable] the `sessions` module.
|
||||
|
||||
This will enable the `$jetty.home/etc/sessions/id-manager.xml` file and generate a `$jetty.base/start.d/sessions.ini` file.
|
||||
|
||||
The `$jetty.home/etc/sessions/id-manager.xml` file instantiates a singleton DefaultSessionIdManager and HouseKeeper and configures them using the properties from the `$jetty.base/start.d/sessions.ini` file.
|
||||
|
||||
Edit the file to change the properties to easily customize the DefaultSessionIdManager and HouseKeeper:
|
||||
|
||||
jetty.sessionIdManager.workerName::
|
||||
By default it is `node1`.
|
||||
This uniquely identifies the jetty server instance within a cluster.
|
||||
If you have more than one jetty instance, it is crucial that you configure the worker name differently on each jetty instance.
|
||||
|
||||
|
||||
jetty.sessionScavengeInterval.seconds::
|
||||
This is the period in seconds between runs of the session scavenger.
|
||||
By default it will run every 600 secs (ie 10 mins).
|
||||
As a rule of thumb, you should ensure that the scavenge interval is shorter than the maxInactiveInterval of your sessions to ensure that they are promptly scavenged.
|
||||
|
||||
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
[[configuring-sessions-infinispan]]
|
||||
|
||||
=== Clustered Session Management: Inifinspan
|
||||
=== Persisted Sessions: Inifinspan
|
||||
|
||||
==== Enabling Infinispan Sessions
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
[[configuring-sessions-jdbc]]
|
||||
|
||||
=== Clustered Session Management: JDBC
|
||||
=== Persisted Sessions: JDBC
|
||||
|
||||
==== Enabling JDBC Sessions
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,63 @@
|
|||
// ========================================================================
|
||||
// Copyright (c) 1995-2017 Mort Bay Consulting Pty. Ltd.
|
||||
// ========================================================================
|
||||
// All rights reserved. This program and the accompanying materials
|
||||
// are made available under the terms of the Eclipse Public License v1.0
|
||||
// and Apache License v2.0 which accompanies this distribution.
|
||||
//
|
||||
// The Eclipse Public License is available at
|
||||
// http://www.eclipse.org/legal/epl-v10.html
|
||||
//
|
||||
// The Apache License v2.0 is available at
|
||||
// http://www.opensource.org/licenses/apache2.0.php
|
||||
//
|
||||
// You may elect to redistribute this code under either of these licenses.
|
||||
// ========================================================================
|
||||
|
||||
[[session-configuration-memcachedsessiondatastore]]
|
||||
=== Persisted Sessions: The L2 Session Data Cache
|
||||
|
||||
If your chosen persistence technology is slow, it can be helpful to locally cache the session data.
|
||||
The `CachingSessionDataStore` is a special type of `SessionDataStore` that locally caches session data, which makes reads faster. It writes-through to your chosen type of `SessionDataStore` when session data changes.
|
||||
|
||||
==== MemcachedSessionDataMap
|
||||
|
||||
The `MemcachedSessionDataMap` uses `memcached` to perform caching.
|
||||
|
||||
To enable it with the jetty distribution, use the `session-store-cache` link:#startup-modules[module], along with your chosen `session-store-xxxx` module of course, and optionally the `session-cache-hash` or `session-cache-null` modules.
|
||||
|
||||
After enabling, the `$jetty.base/start.d/session-store-cache.ini` file will be generated:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
----
|
||||
--module=session-store-cache
|
||||
|
||||
|
||||
## Session Data Cache type: xmemcached
|
||||
session-data-cache=xmemcached
|
||||
#jetty.session.memcached.host=localhost
|
||||
#jetty.session.memcached.port=11211
|
||||
#jetty.session.memcached.expirySec=
|
||||
#jetty.session.memcached.heartbeats=true
|
||||
----
|
||||
|
||||
|
||||
The configuration properties are:
|
||||
|
||||
jetty.session.memcached.host::
|
||||
Default value is `localhost`.
|
||||
This is the host on which the memcached server resides.
|
||||
|
||||
jetty.session.memcached.port::
|
||||
Default value is `11211`.
|
||||
This is the port on which the memcached server is listening.
|
||||
|
||||
jetty.session.memcached.expirySec::
|
||||
Default value `0`.
|
||||
This is the length of time in seconds that an item can remain in the memcached cache, where 0 indicates indefinitely.
|
||||
|
||||
|
||||
jetty.session.memcached.heartbeats::
|
||||
Default value `true`.
|
||||
Whether or not the memcached system should generate heartbeats.
|
||||
|
||||
|
|
@ -16,21 +16,17 @@
|
|||
|
||||
[[configuring-sessions-memory]]
|
||||
|
||||
=== Non-Clustered Session Management: Memory
|
||||
=== Non-persisted Sessions
|
||||
|
||||
Non-clustered, in-memory-only is the default style of Session Management.
|
||||
Non-clustered, non-persisted, in-memory-only is the default style of session management.
|
||||
In previous versions of Jetty this was referred to as "hash" sessions, as they were stored in a `HashMap` in memory.
|
||||
When using the Jetty distribution, if you do not configure any session module, this will be enabled by default.
|
||||
|
||||
Specifically, Jetty will hook up:
|
||||
This is delivered by a combination of the `DefaultSessionCache` (to keep sessions in memory) and a `NullSessionDataStore` (to avoid session persistence).
|
||||
|
||||
A `DefaultSessionIdManager`::
|
||||
* Produces unique session ids and supports cross-context dispatch re-use of session ids
|
||||
A `HouseKeeper`::
|
||||
* Scavenges for expired sessions every 10 mins
|
||||
A `DefaultSessionCache` per context::
|
||||
* Keeps session objects in memory
|
||||
A `NullSessionDataStore` per context::
|
||||
* No persistence of sessions
|
||||
If you do nothing, then jetty will instantiate one of each of these objects for each context at startup time using hard-coded defaults.
|
||||
|
||||
To explicitly set up non-persisted sessions using modules, use both the `session-cache-hash` and the `session-store-null` modules.
|
||||
|
||||
Enabling the modules allows you to configure behaviour - see link:#session-configuration-sessioncache[The L1 Session Cache] for detailed information on configuration options for the `DefaultSessionCache`.
|
||||
As it is so trivial, the `NullSessionDataStore` has no customizable options.
|
||||
|
||||
If you wish to change any of the default configuration, enable the `session-cache-hash` module.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
[[configuring-sessions-mongo]]
|
||||
|
||||
=== Clustered Session Management: MongoDB
|
||||
=== Persisted Sessions: MongoDB
|
||||
|
||||
==== Enabling MongoDB Sessions
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,69 @@
|
|||
// ========================================================================
|
||||
// Copyright (c) 1995-2017 Mort Bay Consulting Pty. Ltd.
|
||||
// ========================================================================
|
||||
// All rights reserved. This program and the accompanying materials
|
||||
// are made available under the terms of the Eclipse Public License v1.0
|
||||
// and Apache License v2.0 which accompanies this distribution.
|
||||
//
|
||||
// The Eclipse Public License is available at
|
||||
// http://www.eclipse.org/legal/epl-v10.html
|
||||
//
|
||||
// The Apache License v2.0 is available at
|
||||
// http://www.opensource.org/licenses/apache2.0.php
|
||||
//
|
||||
// You may elect to redistribute this code under either of these licenses.
|
||||
// ========================================================================
|
||||
|
||||
[[session-configuration-sessioncache]]
|
||||
=== The L1 Session Cache
|
||||
|
||||
==== The DefaultSessionCache
|
||||
|
||||
In the absence of any explicit configuration, jetty will instantiate an instance of the `DefaultSessionCache` per context.
|
||||
If you wish to change any of the defaulted values, you need to enable the `sesssion-cache-hash` link:#startup-modules[module].
|
||||
|
||||
Opening `start.d/session-cache-hash.ini` will show a list of all the configurable options:
|
||||
|
||||
[source, screen, subs="{sub-order}"]
|
||||
----
|
||||
--module=session-cache-hash
|
||||
|
||||
#jetty.session.evictionPolicy=-1
|
||||
#jetty.session.saveOnInactiveEvict=false
|
||||
#jetty.session.saveOnCreate=false
|
||||
#jetty.session.removeUnloadableSessions=false
|
||||
----
|
||||
|
||||
jetty.session.evictionPolicy::
|
||||
Integer.
|
||||
Controls whether session objects that are held in memory are subject to eviction from the memory cache.
|
||||
Evicting sessions can reduce the memory footprint of the cache.
|
||||
Eviction is usually used in conjunction with a `SessionDataStore` that persists sessions.
|
||||
If you are not using a `SessionDataStore` that persists sessions, then be aware that evicted sessions will be lost.
|
||||
Values are:
|
||||
* -1 : sessions are never evicted from the cache
|
||||
* 0 : sessions are evicted from the cache as soon as the last active request for it finishes
|
||||
* >= 1 : any positive number is the time in seconds after which a session that is in the cache but has not experienced any activity will be evicted
|
||||
|
||||
jetty.session.saveOnInactiveEvict::
|
||||
Boolean, default `false`.
|
||||
Controls whether a session will be saved to the `SessionDataStore` just prior to its eviction.
|
||||
|
||||
jetty.session.saveOnCreate::
|
||||
Boolean, default `false`.
|
||||
Controls whether a session that is newly created will be immediately saved to the `SessionDataStore` or lazily saved as the last request for the session exits.
|
||||
|
||||
jetty.session.removeUnloadableSessions::
|
||||
Boolean, default `false`.
|
||||
Controls whether a session that cannot be restored - for example because it is corrupted - from the `SessionDataStore` is deleted by the `SessionDataStore`.
|
||||
|
||||
For more general information on the uses of these configuration properties, see link:#sessions-details[Session Components].
|
||||
|
||||
|
||||
==== The NullSessionCache
|
||||
|
||||
The `NullSessionCache` is a trivial implementation of the `SessionCache` that does not cache any session information.
|
||||
You may need to use it if your clustering setup does not have a sticky load balancer, or if you want absolutely minimal support for sessions.
|
||||
If you use this in conjunction with the `NullSessionDataStore`, then sessions will neither be retained in memory nor persisted.
|
||||
|
||||
To enable the `NullSessionCache`, enable the `sesssion-cache-null` link:#startup-modules[module].
|
||||
|
|
@ -49,8 +49,11 @@ image::images/SessionsHierarchy.png[]
|
|||
|
||||
==== Configuring Sessions in the Jetty Distribution
|
||||
|
||||
Jetty provides support for several different Session Management technologies.
|
||||
Both link:#configuring-sessions-file-system[local file storage] and in-memory session management can be implemented for standard implementations.
|
||||
For implementations using clustered technologies, link:#configuring-sessions-jdbc[JDBC], link:#configuring-sessions-mongo[MongoDB], link:#configuring-sessions-infinispan[Inifinispan] and link:#configuring-sessions-gcloud[Google Cloud Datastore] are all supported.
|
||||
Setting up these technologies is as easy as enabling it's link:#startup-modules[module] and editing it's associated ini file with any usernames, passwords or changes you need to make for your instance.
|
||||
The following sections will cover how exactly to enable the required modules as well as an overview of what options are available for customization.
|
||||
Configuring session management involves selecting a link:#startup-modules[module] for the desired type of link:#session-configuration-sessioncache[session caching] behaviour, and a module for the type of session persistance.
|
||||
|
||||
Jetty provides two different session caches: the `DefaultSessionCache` which holds sessions in memory, and the `NullSessionCache` which does not.
|
||||
There is more information on both of these types of session caching and the circumstances which would lead you to select one or the other in the link:#sessions-details[Session Components] section, and more information on the configuration options of each in link:#session-configuration-sessioncache[The L1 Session Cache] section.
|
||||
|
||||
For session persistence, jetty provides a number of different implementations from which to choose including link:#configuring-sessions-memory[non-persistence], link:#configuring-sessions-file-system[local file storage], clustered technologies such as link:#configuring-sessions-jdbc[JDBC], link:#configuring-sessions-mongo[MongoDB], link:#configuring-sessions-infinispan[Inifinispan], link:#configuring-sessions-gcloud[Google Cloud Datastore], and link:#configuring-sessions-hazelcast[Hazelcast].
|
||||
|
||||
Depending on your persistence technology, to enhance performance, you might want to use an L2 cache for session data, in which case jetty provides the link:#session-configuration-memcachedsessiondatastore[memcached L2 session data cache].
|
||||
|
|
|
|||
|
|
@ -15,11 +15,9 @@
|
|||
// ========================================================================
|
||||
|
||||
[[sessions-details]]
|
||||
=== Session Configuration and Use Cases
|
||||
=== Session Components
|
||||
|
||||
==== Configuration
|
||||
|
||||
===== SessionIdManager
|
||||
==== SessionIdManager
|
||||
|
||||
There is a maximum of 1 `SessionIdManager` per jetty Server instance.
|
||||
Its purpose is to generate fresh, unique session ids and to coordinate the re-use of session ids amongst co-operating contexts.
|
||||
|
|
@ -31,22 +29,26 @@ If you do not explicitly enable one of the session modules, or otherwise configu
|
|||
|
||||
If the `DefaultSessionIdManager` does not meet your needs, you can extend the `org.eclipse.jetty.server.session.AbstractSessionIdManager` or do a fresh implementation of the `org.eclipse.jetty.server.session.SessionIdManager` interface.
|
||||
|
||||
===== HouseKeeper
|
||||
See link:#session-configuration-housekeeper[Configuring the SessionIdManager and HouseKeeper] for details on configuration.
|
||||
|
||||
==== HouseKeeper
|
||||
|
||||
There is a maximum of 1 `HouseKeeper` per `SessionIdManager`.
|
||||
Its purpose is to periodically poll the `SessionHandlers` to clean out expired sessions.
|
||||
|
||||
By default the `HouseKeeper` will poll the `SessionHandlers` every 10 mins to find and delete expired sessions, although this interval is configurable.
|
||||
|
||||
See link:#session-configuration-housekeeper[Configuring the SessionIdManager and HouseKeeper] for details on configuration.
|
||||
|
||||
===== SessionCache
|
||||
|
||||
==== SessionCache
|
||||
|
||||
There is 1 `SessionCache` per context.
|
||||
Its purpose is to provide an L1 cache of Session objects.
|
||||
Having a working set of Session objects in memory allows multiple simultaneous requests for the same session to share the same Session object.
|
||||
|
||||
Jetty provides 2 `SessionCache` implementations: the `DefaultSessionCache` and the `NullSessionCache`.
|
||||
The `DefaultSessionCache` retains Session objects in memory in a cache and has a number of configuration options to control cache behavior.
|
||||
The `DefaultSessionCache` retains Session objects in memory in a cache and has a number of link:#session-configuration-sessioncache[configuration options] to control cache behavior.
|
||||
It is the default that is used if no other `SessionCache` has been configured.
|
||||
It is suitable for non-clustered and clustered deployments with a sticky load balancer, as well as clustered deployments with a non-sticky load balancer, with some caveats.
|
||||
The `NullSessionCache` does not actually cache any objects: each request uses a fresh Session object.
|
||||
|
|
@ -58,9 +60,11 @@ They can also be configured to do an immediate, eager write of a freshly created
|
|||
This can be useful if you are likely to experience multiple, near simultaneous requests referencing the same session, e.g. with HTTP/2 and you don't have a sticky load balancer.
|
||||
Alternatively, if the eager write is not done, application paths which create and then invalidate a session within a single request never incur the cost of writing to persistent storage.
|
||||
|
||||
Additionally, if the `EVICT_ON_INACTIVITY` eviction policy is in use, you can configure the `DefaultSessionCache` to force a write of the Session to the SessionDataStore just before the Session is evicted.
|
||||
Additionally, if the `EVICT_ON_INACTIVITY` eviction policy is in use, you can link:#session-configuration-sessioncache[configure] the `DefaultSessionCache` to force a write of the Session to the SessionDataStore just before the Session is evicted.
|
||||
|
||||
===== SessionDataStore
|
||||
See link:#session-configuration-sessioncache[The L1 Session Cache] for more information.
|
||||
|
||||
==== SessionDataStore
|
||||
|
||||
There is 1 `SessionDataStore` per context. Its purpose is to handle all persistence related operations on sessions.
|
||||
|
||||
|
|
@ -79,8 +83,12 @@ When `SessionDataStores` search their persistent store to find sessions that hav
|
|||
* The second finds sessions in the store that have expired which were last live on the current node
|
||||
* The third finds sessions that expired a "while" ago, irrespective of on which node they were last used: the definition of "a while" is based on the grace period.
|
||||
|
||||
Jetty instantiates the trivial `NullSessionDataStore` - which does not persist sessions - as the default.
|
||||
|
||||
===== CachingSessionDataStore
|
||||
The distribution provides a number of alternative `SessionDataStore` implementations such as link:#configuring-sessions-file-system[FileSessionDataStore], link:#configuring-sessions-gcloud[GCloudSessionDataStore], link:#configuring-sessions-jdbc[JDBCSessionDataStore], link:#configuring-sessions-mongodb[MongoSessionDataStore], link:#configuring-sessions-infinispan[InfinispanSessionDataStore], link:#configuring-sessions-hazelcast[HazelcastSessionDataStore].
|
||||
|
||||
|
||||
==== CachingSessionDataStore
|
||||
|
||||
The `CachingSessionDataStore` is a special type of `SessionDataStore` that inserts an L2 cache of SessionData - the `SessionDataMap` - in front of a delegate `SessionDataStore`.
|
||||
The `SessionDataMap` is preferentially consulted before the actual SessionDataStore on reads.
|
||||
|
|
@ -88,47 +96,4 @@ This can improve the performance of slow stores.
|
|||
|
||||
Jetty provides one implementation of the this L2 cache based on `Memcached`, the `MemcachedSessionDataMap`.
|
||||
|
||||
|
||||
==== Use Cases
|
||||
|
||||
===== Clustering with a Sticky Load Balancer
|
||||
|
||||
Preferably, your cluster will utilize a sticky load balancer.
|
||||
This will route requests for the same session to the same Jetty instance.
|
||||
In this case, the `DefaultSessionCache` can be used to keep in-use Session objects in memory.
|
||||
You can fine-tune the cache by controlling how long Session objects remain in memory with the eviction policy settings.
|
||||
|
||||
If you have a large number of Sessions or very large Session objects, then you might want to manage your memory allocation by controlling the amount of time Session objects spend in the cache.
|
||||
The `EVICT_ON_SESSION_EXIT` eviction policy will remove a Session object from the cache as soon as the last simultaneous request referencing it exits.
|
||||
Alternatively, the `EVICT_ON_INACTIVITY` policy will remove a Session object from the cache after a configurable amount of time has passed without a request referencing it.
|
||||
|
||||
If your Sessions are very long lived and infrequently referenced, you might use the `EVICT_ON_INACTIVITY_POLICY` to control the size of the cache.
|
||||
|
||||
If your Sessions are small, or relatively few or stable in number or they are read-mostly, then you might select the `NEVER_EVICT` policy.
|
||||
With this policy, Session objects will remain in the cache until they either expire or are explicitly invalidated.
|
||||
|
||||
If you have a high likelihood of simultaneous requests for the same session object, then the `EVICT_ON_SESSION_EXIT` policy will ensure the Session object stays in the cache as long as it is needed.
|
||||
|
||||
|
||||
===== Clustering without a Sticky Load Balancer
|
||||
|
||||
Without a sticky load balancer requests for the same session may arrive on any node in the cluster.
|
||||
This means it is likely that the copy of the Session object in any `SessionCache` is likely to be out-of-date, as the Session was probably last accessed on a different node.
|
||||
In this case, your `choices` are to use either the `NullSessionCache` or to de-tuned the `DefaultSessionCache`.
|
||||
If you use the NullSessionCache all Session object caching is avoided.
|
||||
This means that every time a request references a session it must be brought in from persistent storage.
|
||||
It also means that there can be no sharing of Session objects for multiple requests for the same session: each will have their own Session object.
|
||||
Furthermore, the outcome of session writes are indeterminate because the Servlet Specification does not mandate ACID transactions for sessions.
|
||||
|
||||
If you use the `DefaultSessionCache`, there is a risk that the caches on some nodes will contain out-of-date session information as simultaneous requests for the same session are scattered over the cluster.
|
||||
To mitigate this somewhat you can use the `EVICT_ON_SESSION_EXIT` eviction policy: this will ensure that the Session is removed from the cache as soon as the last simultaneous request for it exits.
|
||||
Again, due to the lack of session transactionality, the ordering outcome of write operations cannot be guaranteed.
|
||||
As the Session is cached while at least one request is accessing it, it is possible for multiple simultaneous requests to share the same Session object.
|
||||
|
||||
|
||||
===== Handling corrupted or unloadable session data
|
||||
|
||||
For various reasons it might not be possible for the SessionDataStore to re-read a stored session.
|
||||
One scenario is that the session stores a serialized object in it's attributes, and after a redeployment there in an incompatible class change.
|
||||
Using the setter `SessionCache.setRemoveUnloadableSessions(true)` will allow the `SessionDataStore` to delete the unreadable session from persistent storage.
|
||||
This can be useful from preventing the scavenger from continually generating errors on the same expired, but un-restorable, session.
|
||||
See link:#session-configuration-memcachedsessiondatastore[The L2 SessionData Cache].
|
||||
|
|
|
|||
|
|
@ -0,0 +1,60 @@
|
|||
// ========================================================================
|
||||
// Copyright (c) 1995-2017 Mort Bay Consulting Pty. Ltd.
|
||||
// ========================================================================
|
||||
// All rights reserved. This program and the accompanying materials
|
||||
// are made available under the terms of the Eclipse Public License v1.0
|
||||
// and Apache License v2.0 which accompanies this distribution.
|
||||
//
|
||||
// The Eclipse Public License is available at
|
||||
// http://www.eclipse.org/legal/epl-v10.html
|
||||
//
|
||||
// The Apache License v2.0 is available at
|
||||
// http://www.opensource.org/licenses/apache2.0.php
|
||||
//
|
||||
// You may elect to redistribute this code under either of these licenses.
|
||||
// ========================================================================
|
||||
|
||||
[[sessions-usecases]]
|
||||
=== Use Cases
|
||||
|
||||
===== Clustering with a Sticky Load Balancer
|
||||
|
||||
Preferably, your cluster will utilize a sticky load balancer.
|
||||
This will route requests for the same session to the same Jetty instance.
|
||||
In this case, the `DefaultSessionCache` can be used to keep in-use Session objects in memory.
|
||||
You can fine-tune the cache by controlling how long Session objects remain in memory with the eviction policy settings.
|
||||
|
||||
If you have a large number of Sessions or very large Session objects, then you might want to manage your memory allocation by controlling the amount of time Session objects spend in the cache.
|
||||
The `EVICT_ON_SESSION_EXIT` eviction policy will remove a Session object from the cache as soon as the last simultaneous request referencing it exits.
|
||||
Alternatively, the `EVICT_ON_INACTIVITY` policy will remove a Session object from the cache after a configurable amount of time has passed without a request referencing it.
|
||||
|
||||
If your Sessions are very long lived and infrequently referenced, you might use the `EVICT_ON_INACTIVITY_POLICY` to control the size of the cache.
|
||||
|
||||
If your Sessions are small, or relatively few or stable in number or they are read-mostly, then you might select the `NEVER_EVICT` policy.
|
||||
With this policy, Session objects will remain in the cache until they either expire or are explicitly invalidated.
|
||||
|
||||
If you have a high likelihood of simultaneous requests for the same session object, then the `EVICT_ON_SESSION_EXIT` policy will ensure the Session object stays in the cache as long as it is needed.
|
||||
|
||||
|
||||
===== Clustering without a Sticky Load Balancer
|
||||
|
||||
Without a sticky load balancer requests for the same session may arrive on any node in the cluster.
|
||||
This means it is likely that the copy of the Session object in any `SessionCache` is likely to be out-of-date, as the Session was probably last accessed on a different node.
|
||||
In this case, your `choices` are to use either the `NullSessionCache` or to de-tune the `DefaultSessionCache`.
|
||||
If you use the NullSessionCache all Session object caching is avoided.
|
||||
This means that every time a request references a session it must be brought in from persistent storage.
|
||||
It also means that there can be no sharing of Session objects for multiple requests for the same session: each will have their own Session object.
|
||||
Furthermore, the outcome of session writes are indeterminate because the Servlet Specification does not mandate ACID transactions for sessions.
|
||||
|
||||
If you use the `DefaultSessionCache`, there is a risk that the caches on some nodes will contain out-of-date session information as simultaneous requests for the same session are scattered over the cluster.
|
||||
To mitigate this somewhat you can use the `EVICT_ON_SESSION_EXIT` eviction policy: this will ensure that the Session is removed from the cache as soon as the last simultaneous request for it exits.
|
||||
Again, due to the lack of session transactionality, the ordering outcome of write operations cannot be guaranteed.
|
||||
As the Session is cached while at least one request is accessing it, it is possible for multiple simultaneous requests to share the same Session object.
|
||||
|
||||
|
||||
===== Handling corrupted or unloadable session data
|
||||
|
||||
For various reasons it might not be possible for the SessionDataStore to re-read a stored session.
|
||||
One scenario is that the session stores a serialized object in it's attributes, and after a redeployment there in an incompatible class change.
|
||||
Using the setter `SessionCache.setRemoveUnloadableSessions(true)` will allow the `SessionDataStore` to delete the unreadable session from persistent storage.
|
||||
This can be useful from preventing the scavenger from continually generating errors on the same expired, but un-restorable, session.
|
||||
|
|
@ -628,7 +628,7 @@ public abstract class AbstractSessionCache extends ContainerLifeCycle implements
|
|||
{
|
||||
|
||||
boolean dsdel = _sessionDataStore.delete(id);
|
||||
if (LOG.isDebugEnabled()) LOG.debug("Session {} deleted in db {}",id, dsdel);
|
||||
if (LOG.isDebugEnabled()) LOG.debug("Session {} deleted in session data store {}",id, dsdel);
|
||||
}
|
||||
|
||||
//delete it from the session object store
|
||||
|
|
@ -656,7 +656,7 @@ public abstract class AbstractSessionCache extends ContainerLifeCycle implements
|
|||
return Collections.emptySet();
|
||||
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("SessionDataStore checking expiration on {}", candidates);
|
||||
LOG.debug("{} checking expiration on {}", this, candidates);
|
||||
Set<String> allCandidates = _sessionDataStore.getExpired(candidates);
|
||||
Set<String> sessionsInUse = new HashSet<>();
|
||||
if (allCandidates != null)
|
||||
|
|
|
|||
|
|
@ -261,7 +261,7 @@ public class HouseKeeper extends AbstractLifeCycle
|
|||
return;
|
||||
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("Scavenging sessions");
|
||||
LOG.debug("{} scavenging sessions", this);
|
||||
|
||||
//find the session managers
|
||||
for (SessionHandler manager:_sessionIdManager.getSessionHandlers())
|
||||
|
|
|
|||
|
|
@ -1265,7 +1265,7 @@ public class SessionHandler extends ScopedHandler
|
|||
Set<String> candidates = new HashSet<String>(Arrays.asList(ss));
|
||||
_candidateSessionIdsForExpiry.removeAll(candidates);
|
||||
if (LOG.isDebugEnabled())
|
||||
LOG.debug("Scavenging session ids {}", candidates);
|
||||
LOG.debug("{} scavenging session ids {}", this, candidates);
|
||||
try
|
||||
{
|
||||
candidates = _sessionCache.checkExpiration(candidates);
|
||||
|
|
|
|||
Loading…
Reference in New Issue