Spring/spring-integration
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

INT-3587: JMS OG - Lazy Reply Container Init.

Browse Source 
JIRA: https://jira.spring.io/browse/INT-3587

Start the reply container on demand; stop after a timeout.

INT-3587: Polishing; PR Comments
This commit is contained in:
Gary Russell
2015-07-16 12:42:56 -04:00
committed by Artem Bilan
parent 9e0b2fb319
commit a8f47ee343
8 changed files with 241 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
src/reference/asciidoc/jms.adoc
View File

@@ -254,9 +254,9 @@ Note that, in this situation, a new consumer is used for each request, and consu
[source,xml]
----
<int-jms:outbound-gateway id="jmsOutGateway"
request-destination="outQueue"
request-channel="outboundJmsRequests"
reply-channel="jmsReplies">
request-destination="outQueue"
request-channel="outboundJmsRequests"
reply-channel="jmsReplies">
<int-jms:reply-listener />
</int-jms-outbound-gateway>
----
@@ -266,6 +266,20 @@ The listener is very lightweight and it is anticipated that, in most cases, only
However, attributes such as _concurrent-consumers_, _max-concurrent-consumers_ etc., can be added.
Refer to the schema for a complete list of supported attributes, together with thehttp://static.springsource.org/spring/docs/current/spring-framework-reference/html/jms.html[Spring JMS documentation] for their meanings.
*Idle Reply Listeners*
Starting with _version 4.2_, the reply listener can be started as needed (and stopped after an idle time) instead
of running for the duration of the gateway's lifecycle.
This might be useful if you have many gateways in the application context where they are mostly idle.
One such situation is a context with many (inactive) partitioned http://projects.spring.io/spring-batch/[Spring Batch]
jobs using Spring Integration and JMS for partition distribution.
If all the reply listeners were active, the JMS broker would have an active consumer for each gateway.
By enabling the idle timeout, each consumer would exist only while the corresponding batch job is running (and
for a short time after it finishes).
See `idle-reply-listener-timeout` in <<jms-og-attributes>>.
[[jms-og-attributes]]
==== Attribute Reference
[source,xml]
@@ -295,7 +309,8 @@ Refer to the schema for a complete list of supported attributes, together with t
request-pub-sub-domain="" <22>
time-to-live="" <23>
requires-reply=""> <24>
<int-jms:reply-listener /> <25>
idle-reply-listener-timeout <25>
<int-jms:reply-listener /> <26>
</int-jms:outbound-gateway>
----
@@ -401,8 +416,15 @@ This value is `true` by default, and a `MessageTimeoutException` will be thrown
Note, it is important to keep in mind that, if the service is never expected to return a reply, it would be better to use a `<int-jms:outbound-channel-adapter/>` instead of a `<int-jms:outbound-gateway/>` with `requires-reply="false"`.
With the latter, the sending thread is blocked, waiting for a reply for the `receive-timeout` period.
<25> When a `<reply-listener />` is used, it's lifecycle (start/stop) matches that of the gateway by default.
When this value is greater than `0`, the container is started on demand (when a request is sent).
The container continues to run until at least this time elapses with no requests being received (and no replies
are outstanding).
The container will be started again on the next request.
The stop time is a minimum and may actually be up to 1.5x this value.
<25> When this element is included, replies are received by a `MessageListenerContainer` rather than creating a consumer for each reply.
<26> When this element is included, replies are received by an asynchronous `MessageListenerContainer` rather than
creating a consumer for each reply.
This can be more efficient in many cases.

7
src/reference/asciidoc/whats-new.adoc
View File

@@ -155,6 +155,13 @@ Of course, Reactor is still supported for functionality such as the `Promise` ga
[[x4.2-jms-changes]]
==== JMS Changes
===== Reply Listener Lazy Initialization
It is now possible to configure the reply listener in JMS outbound gateways to be initialized on-demand and stopped
after an idle period, instead of being controlled by the gateway's lifecycle.
See <<jms-outbound-gateway>> for more information.
===== Conversion Errors in Message-Driven Endpoints
The `error-channel` now is used for the conversion errors, which have caused a transaction rollback and message redelivery previously.