Merge branch 'jetty-9.4.x'

This commit is contained in:
Joakim Erdfelt 2016-06-29 15:12:53 -07:00
commit 6f88e74514
5 changed files with 153 additions and 38 deletions

View File

@ -18,13 +18,13 @@
=== Jetty Dump Tool
The dump feature in Jetty provides a good snapshot of the status of the threadpool, select sets, classloaders, and so forth.
To get maximum detail from the dump, you need to `setDetailDump(true)` on any QueuedThreadPools you are using.
To get maximum detail from the dump, you need to `setDetailDump(true)` on any `QueuedThreadPools` you are using.
You can do this by a direct call if you are embedding Jetty, or in `jetty.xml`.
[[configuring-dump-feature]]
==== Configuring the Dump Feature in jetty.xml
You can request that Jetty do a dump immediately after staring and just before stopping by calling the appropriate setters on the Server instance.
You can request that Jetty do a dump immediately after starting and just before stopping by calling the appropriate setters on the `Server` instance.
This can be accomplished in `jetty.xml` with:
[source, xml, subs="{sub-order}"]
@ -36,7 +36,7 @@ This can be accomplished in `jetty.xml` with:
[[extra-threadpool-info]]
==== Extra ThreadPool Information
You can get additional detail from the QueuedThreadPool if `setDetailedDump(true)` is called on the thread pool instance.
You can get additional detail from the `QueuedThreadPool` if `setDetailedDump(true)` is called on the thread pool instance.
Do this in `jetty.xml` as follows:
[source, xml, subs="{sub-order}"]
@ -58,10 +58,10 @@ Do this in `jetty.xml` as follows:
[[dump-tool-via-jmx]]
==== Using the Dump Feature via JMX
The dump method is on the Server instance and many of its nested components (Handlers, Connectors, and so forth).
Dumps may be obtained by calling these methods either in code or via JMX (see ).
The `dump` method is on the Server instance and many of its nested components (Handlers, Connectors, and so forth).
Dumps may be obtained by calling these methods either in code or via JMX (see xref:using-jmx[]).
The Server MBean has a `dump()` method, which dumps everything, plus a `dumpStdErr()` operation that dumps to stderr rather than replying to jconsole.
The Server MBean has a `dump()` method, which dumps everything, plus a `dumpStdErr()` operation that dumps to StdErr rather than replying to JConsole.
[[examing-jetty-distro-dump]]
==== Examining a Jetty Distribution Dump

View File

@ -29,8 +29,8 @@ For those load balancers that examine the session ID, the Jetty persistent sessi
There are two components to session management in Jetty: a session ID manager and a session manager.
* The session ID manager ensures that session IDs are unique across all webapps hosted on a Jetty instance, and thus there can only be one session ID manager per Jetty instance.
* The session manager handles the session lifecycle (create/update/invalidate/expire) on behalf of a web application, so there is one session manager per web application instance.
- The session ID manager ensures that session IDs are unique across all webapps hosted on a Jetty instance, and thus there can only be one session ID manager per Jetty instance.
- The session manager handles the session lifecycle (create/update/invalidate/expire) on behalf of a web application, so there is one session manager per web application instance.
These managers also cooperate and collaborate with the `org.eclipse.jetty.server.session.SessionHandler` to enable cross-context dispatch.
@ -63,43 +63,40 @@ jetty.gcloudSession.workerName::
This value will also be used by the sticky load balancer to identify the node.
Don't forget to change the value of this property on *each* node on which you enable gcloud datastore session clustering.
Which other properties you need to set depends on the execution environment:
====== Running Within Google Infrastructure
===== Configuring GCloud Datastore
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 https://cloud.google.com/datastore/docs/activate[Cloud Datastore documentation], all authorizations...etc. will be provided by the runtime environment.
Things that you will need:
====== Running Externally to Google Infrastructure
- a local installation of the https://cloud.google.com/sdk/[Google Cloud SDK]
- a project id referred to below as [YOUR PROJECT ID]
- to have https://cloud.google.com/datastore/docs/activate[enabled your project id] to use GCloud Datastore
When your app is executing outside of Google, you can either contact a remote Cloud Datastore instance, or a https://cloud.google.com/datastore/docs/tools/devserver[local test dev server] provided by the sdk.
The choice determines which properties you need to set:
====== Using GCloud Datastore from Compute/AppEngine
Contacting an sdk dev server for testing:::
In this case, you need to set up either some _System_ properties or _environment variables_ - *NOT* Jetty properties!
DATASTORE_DATASET;;
This must be the name of your (test) project.
DATASTORE_HOST;;
This is the url of the dev server as described https://cloud.google.com/datastore/docs/tools/devserver#setting_environment_variables[in Google's documentation].
An example may be "http://localhost:9999".
Contacting a remote Cloud Datastore:::
In this case, you need to provide all of the authentication and authorization information explicitly via jetty properties in the ini file:
jetty.gcloudSession.projectId;;
This is the name of your project.
jetty.gcloudSession.p12File;;
This is the location of the p12 key file that is associated with your project.
jetty.gcloudSession.serviceAccount;;
This is the email address that defines your service account for the Cloud Datastore.
jetty.gcloudSession.password;;
This is the password associated with the p12 key file.
If you are running your webapp from within ComputeEngine or AppEngine, you do not need to do anything else in order to configure your GCloud setup. All necessary information will be inferred from the environment by the infrastrcture.
====== Using GCloud Datastore from an external server
If you are running your webapp externally to Google infrastructure, you can still interact with the remote GCloud Datastore service.
Execute the following commands:
- gcloud config set project [YOUR PROJECT ID].
- gcloud auth login
This will populate your environment with the necessary authentication information to allow you to contact the remote GCloud Datastore instance.
====== Using GCloud Datastore local development server
If you would like to locally test your application, you can use the Google Cloud SDK's https://cloud.google.com/datastore/docs/tools/datastore-emulator[GCloud Datastore emulator].
Follow the instructions on the https://cloud.google.com/datastore/docs/tools/datastore-emulator[GCloud Datastore emulator page] to set up your environment.
===== Configuring the GCloudSessionManager
As mentioned elsewhere, there should be one `GCloudSessionManager` per context (e.g. webapp).
It will need to reference the single `GCloudSessionIdManager` from which it derives the Cloud Datastore configuration information.
As mentioned elsewhere, there must be one `SessionManager` per context (e.g. webapp).
Each SessionManager needs to reference the single `GCloudSessionIdManager`.
The way you configure a `GCloudSessionManager` depends on whether you're configuring from a context xml file, 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.
@ -166,3 +163,112 @@ maxQueryResults::
For efficiency it is important to limit the size of the result.
The default is 100.
If 0 or negative numbers are set, the default is used instead.
===== The gcloud-memcached-sessions module
As an optimization, you can have Jetty store your session data into GCloud Datastore but also cache it into memcached. This serves two purposes: faster read-accesses and also better support for non-sticky load balancers (although using a non-sticky load balancer is highly undesirable and not recommended).
You will need to enable the `gcloud-memcached-sessions` link:#startup-modules[module] for your link:#creating-jetty-base[base] using the `--add-to-start` or `--add-to-startd` argument to the link:#startup-overview[start.jar].
If you already enabled the gcloud-sessions module, that's fine as the gcloud-memcached-sessions module depends on it anyway.
Jetty uses the https://github.com/killme2008/xmemcached[Xmemcached] java client.
It depends on http://www.slf4j.org/[slf4j], so you will need to choose an http://www.slf4j.org/[slf4j logging implementation]. You can copy the chosen implementation jars into your $jetty.base/lib/ext directory.
====== Configuring the GCloudSessionIdManager
The instructions here are exactly the same as for the gcloud-sessions module.
====== Configuring GCloud Datastore
The instructions here are exactly the same as for the gcloud-sessions module.
====== Configuring Memcached
If you have installed memcached on a host and port other than the defaults of `localhost` and `11211`, then you will need to take note of these values and supply them to the configuration of the `GCloudMemcachedSessionManager`.
====== Configuring the GCloudMemcachedSessionManager
*Note that* you will be configuring a `GCloudMemcachedSessionManager` 'instead of' a `GCloudSessionManager`.
As usual, there must be only one per context (e.g. webapp).
Each GCloudMemcachedSessionManager needs to reference the single `GCloudSessionIdManager`.
The way you configure a `GCloudMemcachedSessionManager` depends on whether you're configuring from a context xml file, 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:
[source, xml, subs="{sub-order}"]
----
<!-- Get a reference to the GCloudSessionIdManager -->
<Ref id="Server">
<Call id="idMgr" name="getSessionIdManager"/>
</Ref>
<!-- Use the GCloudSessionIdManager to set up the GCloudMemcachedSessionManager -->
<Set name="sessionHandler">
<New class="org.eclipse.jetty.server.session.SessionHandler">
<Arg>
<New id="mgr" class="org.eclipse.jetty.gcloud.memcached.session.GCloudMemcachedSessionManager">
<Set name="sessionIdManager">
<Ref id="idMgr"/>
</Set>
<Set name="scavengeIntervalSec">600</Set>
<Set name="host">myhost</Set>
<Set name="port">11211</Set>
<Set name="expirySec">0</Set>
</New>
</Arg>
</New>
</Set>
----
From a `WEB-INF/jetty-web.xml` file, you can reference the Server instance directly:
[source, xml, subs="{sub-order}"]
----
<!-- Reference the server directly -->
<Get name="server">
<Get id="idMgr" name="sessionIdManager"/>
</Get>
<!-- Apply the SessionIdManager to the GCloudMemcachedSessionManager -->
<Set name="sessionHandler">
<New class="org.eclipse.jetty.server.session.SessionHandler">
<Arg>
<New id="mgr" class="org.eclipse.jetty.gcloud..memcached.session.GCloudMemcachedSessionManager">
<Set name="sessionIdManager">
<Ref id="idMgr"/>
</Set>
<Set name="scavengeIntervalSec">600</Set>
<Set name="host">myhost</Set>
<Set name="port">11211</Set>
<Set name="expirySec">0</Set>
</New>
</Arg>
</New>
</Set>
----
The `GCloudMemcachedSessionManager` supports the following configuration setters:
scavengeIntervalSec::
Time in seconds between runs of a scavenger task that looks for expired old sessions to delete.
The default is 10 minutes.
If set to 0, no scavenging is done.
staleIntervalSec::
The length of time a session can be in memory without being checked against the cluster.
A value of 0 indicates that the session is never checked against the cluster - the current node is considered to be the master for the session.
maxQueryResults::
The maximum number of results to return for a query to find expired sessions.
For efficiency it is important to limit the size of the result.
The default is 100.
If 0 or negative numbers are set, the default is used instead.
host::
The address of the host where the memcached server is running. Defaults to "localhost".
port::
The port on the host where the memcached serer is running. Defaults to "11211".
expirySec::
The time in seconds that an entry in the memcached cache is considered valid. By default, entries are are not aged out of the cached, however they may be evicted due to memory constraints.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 20 KiB

After

Width:  |  Height:  |  Size: 33 KiB

View File

@ -275,7 +275,7 @@ public class ClasspathPattern
continue;
if (entry._package)
{
if (name.startsWith(entry._name))
if (name.startsWith(entry._name) || ".".equals(entry._pattern))
return entry._inclusive;
}
else

View File

@ -82,4 +82,13 @@ public class ClasspathPatternTest
assertFalse(pattern.match("org.example.Nested$Minus$Else"));
}
@Test
public void testMatchAll()
{
pattern.clear();
pattern.add(".");
assertTrue(pattern.match("org.example.Anything"));
assertTrue(pattern.match("org.example.Anything$Else"));
}
}