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

GH-3107: Add errorOnTimeout for TcpInboundGateway

Browse Source 
Fixes https://github.com/spring-projects/spring-integration/issues/3107

The `MessagingGatewaySupport` has an `errorOnTimeout` option to throw
a `MessageTimeoutException` when downstream reply doesn't come back in
time for configured reply timeout

* Expose an `errorOnTimeout` option as a `TcpInboundGateway` ctor
property
* Add new factory methods into a `Tcp` factory for Java DSL
* Ensure a property works as expected in the `IpIntegrationTests`
* Document a new option

* Add a setter for MessagingGatewaySupport.errorOnTimeout option
* Expose an `errorOnTimeout` option on the DSL's `MessagingGatewaySpec`
making all the out-of-the-box inbound gateways possible to react to the
`MessageTimeoutException` when no reply during reply timeout
* Propagate properly `errorOnTimeout` in the `JmsInboundGateway`
* Modify docs respectively

* Improve docs about `errorOnTimeout`
This commit is contained in:
Artem Bilan
2019-11-12 15:08:01 -05:00
committed by Gary Russell
parent 0bbdd3a5f7
commit 72f7c72392
10 changed files with 160 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
src/reference/asciidoc/endpoint-summary.adoc
View File

@@ -223,3 +223,7 @@ The `<int:outbound-channel-adapter>` element lets you send data to a `void` meth
As discussed in <<./gateway.adoc#gateway,Messaging Gateways>>, the `<int:gateway>` element lets any Java program invoke a messaging flow.
Each of these works without requiring any source-level dependencies on Spring Integration.
The equivalent of an outbound gateway in this context is using a service activator (see <<./service-activator.adoc#service-activator,Service Activator>>) to invoke a method that returns an `Object` of some kind.
Starting with version `5.2.2`, all the inbound gateways can be configured with an `errorOnTimeout` boolean flag to throw a `MessageTimeoutException` when the downstream flow doesn't return a reply during the reply timeout.
The timer is not started until the thread returns control to the gateway, so usually it is only useful when the downstream flow is asynchronous or it stops because of a `null` return from some handler, e.g. <<./filter.adoc#filter,filter>>.
Such an exception can be handled on the `errorChannel` flow, e.g. producing a compensation reply for requesting client.

2
src/reference/asciidoc/ip.adoc
View File

@@ -778,7 +778,7 @@ Two additional attributes support this mechanism.
`retry-interval` specifies (in milliseconds) how often the framework tries to reconnect after a connection failure.
`scheduler` supplies a `TaskScheduler` to schedule the connection attempts and to test that the connection is still active.
If the gateway is started, you may force the gateway to establish a connection by sending a <control-bus /> command: `@adapter_id.retryConnection()` and examine the current state with `@adapter_id.isClientModeConnected()`.
If the gateway is started, you may force the gateway to establish a connection by sending a `<control-bus/>` command: `@adapter_id.retryConnection()` and examine the current state with `@adapter_id.isClientModeConnected()`.
The outbound gateway, after sending a message over the connection, waits for a response, constructs a response message, and puts it on the reply channel.
Communications over the connections are single-threaded.