Message-ID: <1040761896.29213.1394375485552.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_29212_2056443302.1394375485551" ------=_Part_29212_2056443302.1394375485551 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Graceful shutdown of a server, context or connector is when existing req=
uest/connections are allowed to gracefully complete while no new requests a=
nd/or connections are accepted. It is configured on the Server instance wit=
setGracefulShutdown(long) method. Here's an example of s=
etting this via the jetty.xml file, where we specify a "grace" pe=
riod of 1000 milliseconds:
The "grace" period is the time the container will wait for req= uests currently inside the container to finish processing before shutting d= own.=20
As soon as the shutdown command is given, the container will close the c= onnectors so that they do not accept any more inbound connections. This wil= l inform most load balancers that the server is no longer part of the clust= er. The contexts are closed so that they do not accept any more requests, b= ut the requests currently inside the container will drain out and the Serve= r instance will shutdown after the grace period expires.=20
You must also call the
setStopAtShutdown(boolean) method wi=
th a value of true for the grace period to take effect.
Even though Jetty will automatically handle a controlled shutdown if you=
setGracefulShutdown(long) method on the Server instan=
ce, sometimes you may want to implement your own shutdown handling, for exa=
mple, shutting down just a single context or a connector. Here's how.
The ContextHandler and all the classes derived from it (Context, WebAppC=
ontext) has a
setShutdown(boolean) method, which if passed tru=
e will prevent the context from accepting new requests. Requests that are c=
urrently being handled by the context are not affected.
Requests that are rejected by a shutdown context are passed to the next = configured context that matches the context path. Note that several context= s can be registered for the same context path, so a new context (or a notif= ication of maintenance context) may be revealed by a shutdown context.= =20
setShutdown(false) can be called to allow the context to =
continue handing new requests.
Once a context is shutdown and the number of requests has reduced to zer=
o (or near zero), then
stop() should be called to actually sto=
p the components of the context.
ContextHandler.setShutdown(boolean) method is exposed o=
n via an MBean and can be called from a management agent.
Connector.close() method can be called to close the ser=
ver socket on which a connector is listening. This will prevent new connect=
ions from being accepted and inform most load balancers that the server is =
no longer part of a cluster. Existing client connections can continue to ru=
n until they timeout or
stop() is called on the connector.
A closed connector should be stopped before being restarted.
ctor.open() cannot be called on a started connector.