Files
spring-integration/src/reference/docbook/shutdown.xml
Gary Russell 6b8bdc7e5e INT-3455 Orderly Shutdown Improvements
JIRA: https://jira.spring.io/browse/INT-3455

Do not stop schedulers and executors - allows mid-flow
QueueChannels to be drained.

Stop all inbound MessageProducers (that are not OrderlyShutdownCapable).

INT-3455 Polishing; PR Comments

Change deprecate method usage to the new version
2014-08-05 22:18:24 +03:00

71 lines
3.8 KiB
XML

<?xml version="1.0" encoding="UTF-8"?>
<section version="5.0" xml:id="jmx-shutdown"
xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:ns5="http://www.w3.org/1999/xhtml"
xmlns:ns4="http://www.w3.org/1998/Math/MathML"
xmlns:ns3="http://www.w3.org/2000/svg"
xmlns:ns="http://docbook.org/ns/docbook">
<title>Orderly Shutdown</title>
<para>
As described in <xref linkend="jmx-mbean-exporter"/>, the MBean exporter provides a JMX operation
<emphasis>stopActiveComponents</emphasis>, which is used to stop the application in an orderly manner. The operation
has a single long parameter.
The parameter indicates how long (in milliseconds) the operation will wait to allow
in-flight messages to complete. The operation works as follows:
</para>
<para>
The first step calls <classname>beforeShutdown()</classname> on all beans that implement
<classname>OrderlyShutdownCapable</classname>. This allows such components to prepare for shutdown.
Examples of components that implement this interface, and what they do with this call include: JMS and
AMQP message-driven adapters stop their listener containers; TCP server connection factories stop
accepting new connections (while keeping existing connections open); TCP inbound endpoints drop (log)
any new messages received; http inbound endpoints return <emphasis>503 - Service Unavailable</emphasis> for any new
requests.
</para>
<para>
The second step stops any active channels, such as JMS- or AMQP-backed channels.
</para>
<para>
The third step stops all <classname>MessageSource</classname>s.
</para>
<para>
The fourth step stops all inbound <classname>MessageProducer</classname>s (that are not
<interfacename>OrderlyShutdownCapable</interfacename>).
</para>
<para>
The fifth step waits for any remaining time left, as defined by the value of the long parameter passed
in to the operation. This is intended to allow any in-flight messages to complete their journeys. It is
therefore important to select an appropriate timeout when invoking this operation.
</para>
<para>
The sixth step calls <classname>afterShutdown()</classname> on all OrderlyShutdownCapable components.
This allows such components to perform final shutdown tasks (closing all open sockets, for example).
</para>
<para>
As discussed in <xref linkend="jmx-mbean-shutdown"/> this operation can be invoked using JMX. If you
wish to programmatically invoke the method, you will need to inject, or otherwise get a reference to,
the <classname>IntegrationMBeanExporter</classname>. If no <code>id</code> attribute is provided on
the <code>&lt;int-jmx:mbean-export/></code> definition, the bean will have a generated name. This
name contains a random component to avoid <classname>ObjectName</classname> collisions if multiple
Spring Integration contexts exist in the same JVM (MBeanServer).
</para>
<para>
For this reason, if you wish to invoke the method programmatically, it is recommended that you
provide the exporter with an <code>id</code> attribute so it can easily be accessed in the
application context.
</para>
<para>
Finally, the operation can be invoked using the <code>&lt;control-bus&gt;</code>; see the
<ulink url="https://github.com/spring-projects/spring-integration-samples/tree/master/intermediate/monitoring"
>monitoring Spring Integration sample application</ulink> for details.
</para>
<important>
The above algorithm was improved in <emphasis>version 4.1</emphasis>. Previously, all task executors
and schedulers were stopped. This could cause mid-flow messages in <classname>QueueChannel</classname>s
to remain. Now, the shutdown leaves pollers running in order to allow these messages to be
drained and processed.
</important>
</section>