![]() Version: 9.3.10.M0 |
private support for your internal/customer projects ... custom extensions and distributions ... versioned snapshots for indefinite support ... scalability guidance for your apps and Ajax/Comet projects ... development services for sponsored feature development
Jetty can support session clustering by persisting sessions to Google Cloud Datastore. Each Jetty instance locally caches sessions for which it has received requests, writing any changes to the session through to the Datastore as the request exits the server. Sessions must obey the Serialization contract, and servlets must call the Session.setAttribute() method to ensure that changes are persisted.
The persistent session mechanism works in conjunction with a load balancer that supports stickiness. Stickiness can be based on various data items, such as source IP address or characteristics of the session ID or a load-balancer specific mechanism. For those load balancers that examine the session ID, the Jetty persistent session mechanism appends a node ID to the session ID, which can be used for routing.
There are two components to session management in Jetty: a session ID manager and a session manager.
These managers also cooperate and collaborate with the
org.eclipse.jetty.server.session.SessionHandler
to enable
cross-context dispatch.
When using the jetty distribution, to enable Cloud Datastore session
persistence, you will first need to enable the gcloud-sessions
module for your base
using the --add-to-start or --add-to-startd argument to the
start.jar.
As part of the module installation, the necessary jars will be
dynamically downloaded and installed to your ${jetty.base}/lib/gcloud
directory. If you need to up or downgrade the version of the jars, then
you can delete the jars that were automatically installed and replace
them. Once you’ve done that, you will need to prevent jetty’s startup
checks from detecting the missing jars. To do that, you can use
--skip-file-validation=glcoud-sessions
argument to start.jar on the
command line, or place that line inside ${jetty.base}/start.ini
to
ensure it is used for every start.
The gcloud-sessions module will have installed file called
${jetty.home}/etc/jetty-gcloud-sessions.xml
. This file configures an
instance of the GCloudSessionIdManager that will be shared across all
webapps deployed on that server. It looks like this:
Unresolved directive in administration/sessions/session-clustering-gcloud-datastore.adoc - include::/home/jesse/src/jetty.project/target/checkout/jetty-documentation/../jetty-gcloud/jetty-gcloud-session-manager/src/main/config/etc/jetty-gcloud-session-store.xml[]
You configure it by setting values for properties. The properties will
either be inserted as commented out in your start.ini
, or your
start.d/gcloud-sessions.ini
file, depending on how you enabled the
module.
The only property you always need to set is the name of the node in the cluster:
Which other properties you need to set depends on the execution environment:
When you upload your webapp to run in Compute Engine, you do not need to set any other properties for jetty. If you follow the instructions in the Cloud Datastore documentation, all authorizations etc will be provided by the runtime environment.
When your app is executing outside of Google, you can either contact a remote Cloud Datastore instance, or a local test dev server provided by the sdk. The choice determines which properties you need to set:
In this case, you need to set up either some System properties or environment variables - NOT jetty properties! +
In this case, you need to provide all of the authentication and authorization information explicitly via jetty properties in the ini file: +
As mentioned elsewhere, there should be one GCloudSessionManager per context (ie webapp). It will need to reference the single GCloudSessionIdManager from which it derives the Cloud Datastore configuration information.
The way you configure a GCloudSessionManager depends on whether you’re
configuring from a context xml file or a jetty-web.xml
file or code.
The basic difference is how you get a reference to the Jetty
org.eclipse.jetty.server.Server
instance.
From a context xml file, you reference the Server instance as a Ref:
<!-- Get a reference to the GCloudSessionIdManager -->
<Ref id="Server">
<Call id="idMgr" name="getSessionIdManager"/>
</Ref>
<!-- Use the GCloudSessionIdManager to set up the GCloudSessionManager -->
<Set name="sessionHandler">
<New class="org.eclipse.jetty.server.session.SessionHandler">
<Arg>
<New id="mgr" class="org.eclipse.jetty.gcloud.session.GCloudSessionManager">
<Set name="sessionIdManager">
<Ref id="idMgr"/>
</Set>
<Set name="scavengeIntervalSec">600</Set>
</New>
</Arg>
</New>
</Set>
From a WEB-INF/jetty-web.xml
file, you can reference the Server
instance directly:
<!-- Reference the server directly -->
<Get name="server">
<Get id="idMgr" name="sessionIdManager"/>
</Get>
<!-- Apply the SessionIdManager to the GCloudSessionManager -->
<Set name="sessionHandler">
<New class="org.eclipse.jetty.server.session.SessionHandler">
<Arg>
<New id="mgr" class="org.eclipse.jetty.gcloud.session.GCloudSessionManager">
<Set name="sessionIdManager">
<Ref id="idMgr"/>
</Set>
<Set name="scavengeIntervalSec">600</Set>
</New>
</Arg>
</New>
</Set>
The GCloudSessionManager supports the following configuration setters: