f30da932e8
This is a significant update to the build system, including the changes listed below. README.md has been updated with instructions on the most important day-to-day commands. - Eliminate buildSrc submodule In favor of using the new bundlor and docbook-reference plugins. The net effect is a large reduction in number of lines of build code. Common docbook resources, stylesheets, etc are stored directly in the docbook plugin. This means that --recursive is no longer required when cloning and there will never be a need to use `git submodule` commands. README files have been updated to reflect. Use of the new bundlor plugin also means the removal of template.mf files from the source tree in favor of an inline approach. See build.gradle for details. Bundlor 'import templates' are built up programmatically and kept physically close to gradle dependency declarations, leading to more convenience when changing these values and hopefully fewer errors / version inconsistencies over time. Certain tests depended on the presence of template.mf files, all of which have recently been removed from the source tree in favor of the new bundlor plugin which allows for inlining bundlor configuration within the Gradle build script. These tests now create temp files using the java.io.File API instead. - Upgrade to Gradle 1.0-milestone-6 The m6 release is significantly faster when resolving dependencies and has a number of valuable new features over the earlier m3 version. Review the release notes for Gradle 1.0-milestone-6 online for full details. - Switch to repo.springsource.org repository Previously the project build declared as many repositories as necessary to resolve all project dependencies. Now depending on a single 'virtual repository' defined within the SpringSource Artifactory instance at http://repo.springsource.org. Currently, the virtual repository in use is 'libs-milestone', which allows for the resolution of all "milestone-or-better" versions of all S2 and third-party dependencies. Should snapshot dependencies become required, this value may be changed from 'libs-milestone' to 'libs-snapshot'. To build only against GA releases, change the value to 'libs-release'. - New build plan(s) Spring Integration build plans have been updated to use the Artifactory Bamboo plugin and publish to repo.springsource.org. Build plans have names like 2.1.x to reflect the version under development, not necessarily the name of the branch, as this may change over time and across major releases. - Improve release process As mentioned above, Spring Integration will now use the Artifactory Bamboo plugin to publish releases and also use Artifactory's support for pushing builds directly into Maven Central via oss.sonatype.org. Generate poms that contain all necessary fields for onboarding at Maven central (scm, developers, organization, licenses, etc). Generate -source and -javadoc poms to comply with Maven Central onboarding rules (and for general good practice anyway). Generation of PGP signatures, sha1 and md5 checksums are all handled automatically by Artifactory. These are also requirements for automated entry into Maven Central. - Remove source-level pom generation Automatic generation of Maven poms suitable for use in building Spring Integration is no longer supported. Generation and publication of poms for the purpose of dependency management remains supported. Sonar support has to date depended on these poms, but will be switched over to use the Gradle Sonar plugin shortly. - Eliminate docs subproject Move docs/src to the root of the project and eliminate docs as a formal subproject. This simplifies the build in a number of ways, including removing the need for distinguishing between 'subprojects' and 'javaprojects' as well as allowing users to build both 'api' and 'reference' docs without qualifying with a ':docs' prefix. Also rename the src/info directory to src/dist to better reflect that these files are packaged with the distribution. For example, the readme.txt there is really the distribution readme, distinct from the README.md at the root of the project which is for building from source, etc.
357 lines
24 KiB
XML
357 lines
24 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<section xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="endpoint"
|
||
xmlns:xlink="http://www.w3.org/1999/xlink">
|
||
<title>Message Endpoints</title>
|
||
<para>
|
||
The first part of this chapter covers some background theory and reveals quite a bit about the underlying API
|
||
that drives Spring Integration's various messaging components. This information can be helpful if you want to
|
||
really understand what's going on behind the scenes. However, if you want to get up and running with the
|
||
simplified namespace-based configuration of the various elements, feel free to skip ahead to
|
||
<xref linkend="endpoint-namespace"/> for now.
|
||
</para>
|
||
<para>
|
||
As mentioned in the overview, Message Endpoints are responsible for connecting the various messaging components to
|
||
channels. Over the next several chapters, you will see a number of different components that consume Messages. Some
|
||
of these are also capable of sending reply Messages. Sending Messages is quite straightforward. As shown above in
|
||
<xref linkend="channel"/>, it's easy to <emphasis>send</emphasis> a Message to a Message Channel. However,
|
||
receiving is a bit more complicated. The main reason is that there are two types of consumers:
|
||
<ulink url="http://www.eaipatterns.com/PollingConsumer.html">Polling Consumers</ulink> and
|
||
<ulink url="http://www.eaipatterns.com/EventDrivenConsumer.html">Event Driven Consumers</ulink>.
|
||
</para>
|
||
<para>
|
||
Of the two, Event Driven Consumers are much simpler. Without any need to manage and schedule a separate poller
|
||
thread, they are essentially just listeners with a callback method. When connecting to one of Spring Integration's
|
||
subscribable Message Channels, this simple option works great. However, when connecting to a buffering, pollable
|
||
Message Channel, some component has to schedule and manage the polling thread(s). Spring Integration provides
|
||
two different endpoint implementations to accommodate these two types of consumers. Therefore, the consumers
|
||
themselves can simply implement the callback interface. When polling is required, the endpoint acts as a
|
||
"container" for the consumer instance. The benefit is similar to that of using a container for hosting
|
||
Message Driven Beans, but since these consumers are simply Spring-managed Objects running within an
|
||
ApplicationContext, it more closely resembles Spring's own MessageListener containers.
|
||
</para>
|
||
|
||
<section id="endpoint-handler">
|
||
<title>Message Handler</title>
|
||
<para>
|
||
Spring Integration's <interfacename>MessageHandler</interfacename> interface is implemented by many of the
|
||
components within the framework. In other words, this is not part of the public API, and a developer would not
|
||
typically implement <interfacename>MessageHandler</interfacename> directly. Nevertheless, it is used by a Message
|
||
Consumer for actually handling the consumed Messages, and so being aware of this strategy interface does help in
|
||
terms of understanding the overall role of a consumer. The interface is defined as follows:
|
||
<programlisting language="java">public interface MessageHandler {
|
||
|
||
void handleMessage(Message<?> message);
|
||
|
||
}</programlisting>
|
||
Despite its simplicity, this provides the foundation for most of the components that will be covered in the
|
||
following chapters (Routers, Transformers, Splitters, Aggregators, Service Activators, etc). Those components
|
||
each perform very different functionality with the Messages they handle, but the requirements for actually
|
||
receiving a Message are the same, and the choice between polling and event-driven behavior is also the same.
|
||
Spring Integration provides two endpoint implementations that "host" these callback-based handlers and allow
|
||
them to be connected to Message Channels.
|
||
</para>
|
||
</section>
|
||
|
||
<section id="endpoint-eventdrivenconsumer">
|
||
<title>Event Driven Consumer</title>
|
||
<para>
|
||
Because it is the simpler of the two, we will cover the Event Driven Consumer endpoint first. You may recall that
|
||
the <interfacename>SubscribableChannel</interfacename> interface provides a <methodname>subscribe()</methodname>
|
||
method and that the method accepts a <interfacename>MessageHandler</interfacename> parameter (as shown in
|
||
<xref linkend="channel-interfaces-subscribablechannel"/>):
|
||
<programlisting language="java">
|
||
subscribableChannel.subscribe(messageHandler);
|
||
</programlisting>
|
||
Since a handler that is subscribed to a channel does not have to actively poll that channel, this is an
|
||
Event Driven Consumer, and the implementation provided by Spring Integration accepts a
|
||
a <interfacename>SubscribableChannel</interfacename> and a <interfacename>MessageHandler</interfacename>:
|
||
<programlisting language="java">SubscribableChannel channel = context.getBean("subscribableChannel", SubscribableChannel.class);
|
||
|
||
EventDrivenConsumer consumer = new EventDrivenConsumer(channel, exampleHandler);</programlisting>
|
||
</para>
|
||
</section>
|
||
|
||
<section id="endpoint-pollingconsumer">
|
||
<title>Polling Consumer</title>
|
||
<para>
|
||
Spring Integration also provides a <classname>PollingConsumer</classname>, and it can be instantiated in
|
||
the same way except that the channel must implement <interfacename>PollableChannel</interfacename>:
|
||
<programlisting language="java">PollableChannel channel = context.getBean("pollableChannel", PollableChannel.class);
|
||
|
||
PollingConsumer consumer = new PollingConsumer(channel, exampleHandler);</programlisting>
|
||
</para>
|
||
<para>
|
||
There are many other configuration options for the Polling Consumer. For example, the trigger is a required property:
|
||
<programlisting language="java">
|
||
PollingConsumer consumer = new PollingConsumer(channel, handler);
|
||
|
||
consumer.setTrigger(new IntervalTrigger(30, TimeUnit.SECONDS));</programlisting>
|
||
Spring Integration currently provides two implementations of the <interfacename>Trigger</interfacename>
|
||
interface: <classname>IntervalTrigger</classname> and <classname>CronTrigger</classname>. The
|
||
<classname>IntervalTrigger</classname> is typically defined with a simple interval (in milliseconds), but
|
||
also supports an 'initialDelay' property and a boolean 'fixedRate' property (the default is false, i.e.
|
||
fixed delay):
|
||
<programlisting language="java">IntervalTrigger trigger = new IntervalTrigger(1000);
|
||
trigger.setInitialDelay(5000);
|
||
trigger.setFixedRate(true);</programlisting>
|
||
The <classname>CronTrigger</classname> simply requires a valid cron expression (see the Javadoc for details):
|
||
<programlisting language="java">CronTrigger trigger = new CronTrigger("*/10 * * * * MON-FRI");</programlisting>
|
||
</para>
|
||
<para>
|
||
In addition to the trigger, several other polling-related configuration properties may be specified:
|
||
<programlisting language="java">
|
||
PollingConsumer consumer = new PollingConsumer(channel, handler);
|
||
|
||
consumer.setMaxMessagesPerPoll(10);
|
||
|
||
consumer.setReceiveTimeout(5000);</programlisting>
|
||
</para>
|
||
<para>
|
||
The 'maxMessagesPerPoll' property specifies the maximum number of messages to receive within a given poll
|
||
operation. This means that the poller will continue calling receive() <emphasis>without waiting</emphasis>
|
||
until either <code>null</code> is returned or that max is reached. For example, if a poller has a 10 second
|
||
interval trigger and a 'maxMessagesPerPoll' setting of 25, and it is polling a channel that has 100 messages
|
||
in its queue, all 100 messages can be retrieved within 40 seconds. It grabs 25, waits 10 seconds, grabs the
|
||
next 25, and so on.
|
||
</para>
|
||
<para>
|
||
The 'receiveTimeout' property specifies the amount of time the poller should wait if no messages are
|
||
available when it invokes the receive operation. For example, consider two options that seem similar on
|
||
the surface but are actually quite different: the first has an interval trigger of 5 seconds and a receive
|
||
timeout of 50 milliseconds while the second has an interval trigger of 50 milliseconds and a receive timeout
|
||
of 5 seconds. The first one may receive a message up to 4950 milliseconds later than it arrived on the channel
|
||
(if that message arrived immediately after one of its poll calls returned). On the other hand, the second
|
||
configuration will never miss a message by more than 50 milliseconds. The difference is that the second
|
||
option requires a thread to wait, but as a result it is able to respond much more quickly to arriving messages.
|
||
This technique, known as "long polling", can be used to emulate event-driven behavior on a polled source.
|
||
</para>
|
||
<para>
|
||
A Polling Consumer may also delegate to a Spring <interfacename>TaskExecutor</interfacename>, and it can
|
||
be configured to participate in Spring-managed transactions. The following example shows the configuration of both:
|
||
<programlisting language="java">
|
||
PollingConsumer consumer = new PollingConsumer(channel, handler);
|
||
|
||
TaskExecutor taskExecutor = context.getBean("exampleExecutor", TaskExecutor.class);
|
||
consumer.setTaskExecutor(taskExecutor);
|
||
|
||
PlatformTransactionManager txManager = context.getBean("exampleTxManager", PlatformTransationManager.class);
|
||
consumer.setTransactionManager(txManager);</programlisting>
|
||
The examples above show dependency lookups, but keep in mind that these consumers will most often be configured
|
||
as Spring <emphasis>bean definitions</emphasis>. In fact, Spring Integration also provides a
|
||
<interfacename>FactoryBean</interfacename> that creates the appropriate consumer type based on the type of
|
||
channel, and there is full XML namespace support to even further hide those details. The namespace-based
|
||
configuration will be featured as each component type is introduced.
|
||
<note>
|
||
Many of the <interfacename>MessageHandler</interfacename> implementations are also capable of generating reply
|
||
Messages. As mentioned above, sending Messages is trivial when compared to the Message reception. Nevertheless,
|
||
<emphasis>when</emphasis> and <emphasis>how many</emphasis> reply Messages are sent depends on the handler
|
||
type. For example, an <emphasis>Aggregator</emphasis> waits for a number of Messages to arrive and is often
|
||
configured as a downstream consumer for a <emphasis>Splitter</emphasis> which may generate multiple
|
||
replies for each Message it handles. When using the namespace configuration, you do not strictly need to know
|
||
all of the details, but it still might be worth knowing that several of these components share a common base
|
||
class, the <classname>AbstractReplyProducingMessageHandler</classname>, and it provides a
|
||
<methodname>setOutputChannel(..)</methodname> method.
|
||
</note>
|
||
</para>
|
||
</section>
|
||
|
||
<section id="endpoint-namespace">
|
||
<title>Namespace Support</title>
|
||
<para>
|
||
Throughout the reference manual, you will see specific configuration examples for endpoint elements, such as
|
||
router, transformer, service-activator, and so on. Most of these will support an "input-channel" attribute and
|
||
many will support an "output-channel" attribute. After being parsed, these endpoint elements produce an instance
|
||
of either the <classname>PollingConsumer</classname> or the
|
||
<classname>EventDrivenConsumer</classname> depending on the type of the "input-channel" that is
|
||
referenced: <interfacename>PollableChannel</interfacename> or <interfacename>SubscribableChannel</interfacename>
|
||
respectively. When the channel is pollable, then the polling behavior is determined based on the endpoint
|
||
element's "poller" sub-element and its attributes. For example, a simple interval-based poller with a 1-second interval would be
|
||
configured like this: <programlisting language="xml"><![CDATA[ <int:transformer input-channel="pollable"
|
||
ref="transformer"
|
||
output-channel="output">
|
||
<int:poller fixed-rate="1000"/>
|
||
</int:transformer>]]></programlisting>
|
||
As an alternative to 'fixed-rate' you can also use the 'fixed-delay' attribute.
|
||
</para>
|
||
<para>
|
||
For a poller based on a Cron expression, use the "cron" attribute instead:
|
||
<programlisting language="xml"><![CDATA[ <int:transformer input-channel="pollable"
|
||
ref="transformer"
|
||
output-channel="output">
|
||
<int:poller cron="*/10 * * * * MON-FRI"/>
|
||
</int:transformer>]]></programlisting>
|
||
</para>
|
||
<para>
|
||
If the input channel is a <interfacename>PollableChannel</interfacename>, then the poller configuration is
|
||
required. Specifically, as mentioned above, the 'trigger' is a required property of the PollingConsumer class.
|
||
Therefore, if you omit the "poller" sub-element for a Polling Consumer endpoint's configuration, an Exception
|
||
may be thrown. The exception will also be thrown if you attempt to configure a poller on the element that is
|
||
connected to a non-pollable channel.
|
||
</para>
|
||
<para>
|
||
It is also possible to create top-level pollers in which case only a "ref" is required:
|
||
<programlisting language="xml"><![CDATA[ <int:poller id="weekdayPoller" cron="*/10 * * * * MON-FRI"/>
|
||
|
||
<int:transformer input-channel="pollable"
|
||
ref="transformer"
|
||
output-channel="output">
|
||
<int:poller ref="weekdayPoller"/>
|
||
</int:transformer>]]></programlisting>
|
||
<note>
|
||
The "ref" attribute is only allowed on the inner-poller definitions. Defining this attribute on a top-level
|
||
poller will result in a configuration exception thrown during initialization of the Application Context.
|
||
</note>
|
||
In fact, to simplify the configuration even further, you can define a global default poller. A single top-level poller within
|
||
an ApplicationContext may have the <code>default</code> attribute with a value of "true". In that case, any
|
||
endpoint with a PollableChannel for its input-channel that is defined within the same ApplicationContext and has
|
||
no explicitly configured 'poller' sub-element will use that default.
|
||
<programlisting language="xml"><![CDATA[ <int:poller id="defaultPoller" default="true" max-messages-per-poll="5" fixed-rate="3000"/>
|
||
|
||
<!-- No <poller/> sub-element is necessary since there is a default -->
|
||
<int:transformer input-channel="pollable"
|
||
ref="transformer"
|
||
output-channel="output"/>]]></programlisting>
|
||
</para>
|
||
<para>
|
||
Spring Integration also provides transaction support for the pollers so that each receive-and-forward
|
||
operation can be performed as an atomic unit-of-work. To configure transactions for a poller, simply add the
|
||
<transactional/> sub-element. The attributes for this element should be familiar to anyone who has
|
||
experience with Spring's Transaction management:
|
||
<programlisting language="xml"><![CDATA[<int:poller fixed-delay="1000">
|
||
<int:transactional transaction-manager="txManager"
|
||
propagation="REQUIRED"
|
||
isolation="REPEATABLE_READ"
|
||
timeout="10000"
|
||
read-only="false"/>
|
||
</int:poller>]]></programlisting>
|
||
|
||
</para>
|
||
<para>
|
||
<emphasis>AOP Advice chains</emphasis>
|
||
</para>
|
||
<para>
|
||
Since Spring transaction support depends on the Proxy mechanism with <classname>TransactionInterceptor</classname> (AOP Advice) handling transactional
|
||
behavior of the message flow initiated by the poler, some times there is a need to provide extra Advice(s) to handle other
|
||
cross cutting behavior associated with the poller. For that poller defines an 'advice-chain' element allowing you to add
|
||
more advices - class that implements <classname>MethodInterceptor</classname> interface..
|
||
<programlisting language="xml"><![CDATA[<int:service-activator id="advicedSa" input-channel="goodInputWithAdvice" ref="testBean"
|
||
method="good" output-channel="output">
|
||
<int:poller max-messages-per-poll="1" fixed-rate="10000">
|
||
<int:transactional transaction-manager="txManager" />
|
||
<int:advice-chain>
|
||
<ref bean="adviceA" />
|
||
<beans:bean class="org.bar.SampleAdvice"/>
|
||
</int:advice-chain>
|
||
</int:poller>
|
||
</int:service-activator>]]></programlisting>
|
||
For more information on how to implement MethodInterceptor please refer to AOP sections of Spring
|
||
reference manual (section 7 and 8). Advice chain can also be applied on the poller that does not have
|
||
any transaction configuration essentially allowing you to enhance the behavior of the message flow initiated by the poller.
|
||
</para>
|
||
<para>
|
||
The polling threads may be executed by any instance of Spring's <interfacename>TaskExecutor</interfacename>
|
||
abstraction. This enables concurrency for an endpoint or group of endpoints. As of Spring 3.0, there is a "task"
|
||
namespace in the core Spring Framework, and its <executor/> element supports the creation of a simple thread
|
||
pool executor. That element accepts attributes for common concurrency settings such as pool-size and queue-capacity.
|
||
Configuring a thread-pooling executor can make a substantial difference in how the endpoint performs under load. These
|
||
settings are available per-endpoint since the performance of an endpoint is one of the major factors to consider
|
||
(the other major factor being the expected volume on the channel to which the endpoint subscribes). To enable
|
||
concurrency for a polling endpoint that is configured with the XML namespace support, provide the 'task-executor'
|
||
reference on its <poller/> element and then provide one or more of the properties shown below:
|
||
<programlisting language="xml"><![CDATA[ <int:poller task-executor="pool" fixed-rate="1000"/>
|
||
|
||
<task:executor id="pool"
|
||
pool-size="5-25"
|
||
queue-capacity="20"
|
||
keep-alive="120"/>]]></programlisting>
|
||
If no 'task-executor' is provided, the consumer's handler will be invoked in the caller's thread. Note that the
|
||
"caller" is usually the default <interfacename>TaskScheduler</interfacename>
|
||
(see <xref linkend="namespace-taskscheduler"/>). Also, keep in mind that the 'task-executor' attribute can
|
||
provide a reference to any implementation of Spring's <interfacename>TaskExecutor</interfacename> interface by
|
||
specifying the bean name. The "executor" element above is simply provided for convenience.
|
||
</para>
|
||
<para>
|
||
As mentioned in the background section for Polling Consumers above, you can also configure a Polling Consumer
|
||
in such a way as to emulate event-driven behavior. With a long receive-timeout and a short interval-trigger,
|
||
you can ensure a very timely reaction to arriving messages even on a polled message source. Note that this
|
||
will only apply to sources that have a blocking wait call with a timeout. For example, the File poller does
|
||
not block, each receive() call returns immediately and either contains new files or not. Therefore, even if
|
||
a poller contains a long receive-timeout, that value would never be usable in such a scenario. On the other
|
||
hand when using Spring Integration's own queue-based channels, the timeout value does have a chance to
|
||
participate. The following example demonstrates how a Polling Consumer will receive Messages nearly
|
||
instantaneously.
|
||
<programlisting language="xml"><![CDATA[ <int:service-activator input-channel="someQueueChannel"
|
||
output-channel="output">
|
||
<int:poller receive-timeout="30000" fixed-rate="10"/>
|
||
|
||
</int:service-activator>]]></programlisting>
|
||
Using this approach does not carry much overhead since internally it is nothing more then a timed-wait thread
|
||
which does not require nearly as much CPU resource usage as a thrashing, infinite while loop for example.
|
||
</para>
|
||
</section>
|
||
|
||
<section id="payload-type-conversion">
|
||
<title>Payload Type Conversion</title>
|
||
<para>
|
||
Throughout the reference manual, you will also see specific configuration and implementation examples of various endpoints
|
||
which can accept a Message or any arbitrary Object as an input parameter. In the case of an Object, such a parameter will
|
||
be mapped to a Message payload or part of the payload or header (when using the Spring Expression Language). However there
|
||
are times when the type of input parameter of the endpoint method does not match the type of the payload or its part.
|
||
In this scenario we need to perform type conversion. Spring Integration provides a convenient way for registering type
|
||
converters (using the Spring 3.x ConversionService) within its own instance of a conversion service bean named <emphasis>integrationConversionService</emphasis>.
|
||
That bean is automatically created as soon as the first converter is defined using the Spring Integration namespace support.
|
||
|
||
To register a Converter all you need is to implement
|
||
<interfacename>org.springframework.core.convert.converter.Converter</interfacename> and define it via
|
||
convenient namespace support:
|
||
<programlisting language="xml"><![CDATA[ <int:converter ref="sampleConverter"/>
|
||
|
||
<bean id="sampleConverter" class="foo.bar.TestConverter"/>]]></programlisting>
|
||
|
||
or as an inner bean:
|
||
<programlisting language="xml"><![CDATA[ <int:converter>
|
||
<bean class="org.springframework.integration.config.xml.ConverterParserTests$TestConverter3"/>
|
||
</int:converter>]]></programlisting>
|
||
</para>
|
||
</section>
|
||
|
||
<section id="async-polling">
|
||
<title>Asynchronous polling</title>
|
||
<para>
|
||
If you want the polling to be asynchronous, a Poller can optionally specify a 'task-executor' attribute
|
||
pointing to an existing instance of any <classname>TaskExecutor</classname> bean
|
||
(Spring 3.0 provides a convenient namespace configuration via the <code>task</code> namespace). However, there are certain things
|
||
you must understand when configuring a Poller with a TaskExecutor.
|
||
</para>
|
||
<para>
|
||
The problem is that there are two configurations in place. The <emphasis>Poller</emphasis> and the <emphasis>TaskExecutor</emphasis>,
|
||
and they both have to be in tune with each other otherwise you might end up creating an artificial memory leak.
|
||
</para>
|
||
<para>
|
||
Let's look at the following configuration provided by one of the users on the Spring Integration
|
||
forum (http://forum.springsource.org/showthread.php?t=94519):
|
||
|
||
<programlisting language="xml"><![CDATA[<int:service-activator input-channel="publishChannel" ref="myService">
|
||
<int:poller receive-timeout="5000" task-executor="taskExecutor" fixed-rate="50"/>
|
||
</int:service-activator>
|
||
|
||
<task:executor id="taskExecutor" pool-size="20" queue-capacity="20"/>]]></programlisting>
|
||
|
||
The above configuration demonstrates one of those out of tune configurations.
|
||
</para>
|
||
<para>
|
||
The poller keeps scheduling new tasks even though all the threads are blocked waiting for either a new message to arrive,
|
||
or the timeout to expire. Given that there are 20 threads executing tasks with a 5 second timeout, they will be executed
|
||
at a rate of 4 per second (5000/20 = 250ms). But, new tasks are being scheduled at a rate of 20 per second, so the internal
|
||
queue in the task executor will grow at a rate of 16 per second (while the process is idle), so we essentially have a memory leak.
|
||
</para>
|
||
<para>
|
||
One of the ways to handle this is to set the <code>queue-capacity</code> attribute of the Task Executor to 0. You can also
|
||
manage it by specifying what to do with messages that can not be queued by setting the <code>rejection-policy</code> attribute
|
||
of the Task Executor (e.g., DISCARD). In other words there are certain details you must understand with regard to configuring
|
||
the TaskExecutor. Please refer to - <emphasis>Section 25 - Task Execution and Scheduling</emphasis> of the Spring reference manual
|
||
for more detail on the subject.
|
||
</para>
|
||
</section>
|
||
</section>
|