You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fixes#3367
Introduce a `requestTimeout` and `triggerTimeout` for `BarrierMessageHandler`
For instance, if an HTTP request sends a message to the barrier,
it should time out after 1min if no trigger message is received.
If the trigger message then arrives late and the HTTP request is no longer waiting,
it shouldn't wait for 1min before discarding the request but do so immediately.
Copy file name to clipboardExpand all lines: spring-integration-core/src/main/java/org/springframework/integration/aggregator/BarrierMessageHandler.java
+73-18Lines changed: 73 additions & 18 deletions
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,5 @@
1
1
/*
2
-
* Copyright 2015-2019 the original author or authors.
2
+
* Copyright 2015-2020 the original author or authors.
3
3
*
4
4
* Licensed under the Apache License, Version 2.0 (the "License");
5
5
* you may not use this file except in compliance with the License.
@@ -39,14 +39,15 @@
39
39
* the timeout occurs. Only one thread with a particular correlation (result of invoking
40
40
* the {@link CorrelationStrategy}) can be suspended at a time. If the inbound thread does
41
41
* not arrive before the trigger thread, the latter is suspended until it does, or the
42
-
* timeout occurs.
42
+
* timeout occurs. Separate timeouts may be configured for request and trigger messages.
43
43
* <p>
44
44
* The default {@link CorrelationStrategy} is a {@link HeaderAttributeCorrelationStrategy}.
45
45
* <p>
46
46
* The default output processor is a {@link DefaultAggregatingMessageGroupProcessor}.
47
47
*
48
48
* @author Gary Russell
49
49
* @author Artem Bilan
50
+
* @author Michel Jung
50
51
*
51
52
* @since 4.2
52
53
*/
@@ -57,7 +58,9 @@ public class BarrierMessageHandler extends AbstractReplyProducingMessageHandler
Copy file name to clipboardExpand all lines: spring-integration-core/src/test/java/org/springframework/integration/config/xml/BarrierParserTests-context.xml
Copy file name to clipboardExpand all lines: src/reference/asciidoc/barrier.adoc
+9-12Lines changed: 9 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,30 +3,27 @@
3
3
4
4
Sometimes, we need to suspend a message flow thread until some other asynchronous event occurs.
5
5
For example, consider an HTTP request that publishes a message to RabbitMQ.
6
-
We might wish to not reply to the user until the RabbitMQ broker has issued an acknowledgment that the message was
7
-
received.
6
+
We might wish to not reply to the user until the RabbitMQ broker has issued an acknowledgment that the message was received.
8
7
9
8
In version 4.2, Spring Integration introduced the `<barrier/>` component for this purpose.
10
9
The underlying `MessageHandler` is the `BarrierMessageHandler`.
11
-
This class also implements
12
-
`MessageTriggerAction`, in which a message passed to the `trigger()` method releases a corresponding thread in the
13
-
`handleRequestMessage()` method (if present).
10
+
This class also implements `MessageTriggerAction`, in which a message passed to the `trigger()` method releases a corresponding thread in the `handleRequestMessage()` method (if present).
14
11
15
12
The suspended thread and trigger thread are correlated by invoking a `CorrelationStrategy` on the messages.
16
-
When a message is sent to the `input-channel`, the thread is suspended for up to `timeout` milliseconds, waiting for
17
-
a corresponding trigger message.
13
+
When a message is sent to the `input-channel`, the thread is suspended for up to `requestTimeout` milliseconds, waiting for a corresponding trigger message.
18
14
The default correlation strategy uses the `IntegrationMessageHeaderAccessor.CORRELATION_ID` header.
19
15
When a trigger message arrives with the same correlation, the thread is released.
20
16
The message sent to the `output-channel` after release is constructed by using a `MessageGroupProcessor`.
21
-
By default, the message is a `Collection<?>` of the two payloads, and the headers are merged by using a
22
-
`DefaultAggregatingMessageGroupProcessor`.
17
+
By default, the message is a `Collection<?>` of the two payloads, and the headers are merged by using a `DefaultAggregatingMessageGroupProcessor`.
23
18
24
-
CAUTION: If the `trigger()` method is invoked first (or after the main thread times out), it is suspended for up to `timeout` waiting for the suspending message to arrive.
19
+
CAUTION: If the `trigger()` method is invoked first (or after the main thread times out), it is suspended for up to `triggerTimeout` waiting for the suspending message to arrive.
25
20
If you do not want to suspend the trigger thread, consider handing off to a `TaskExecutor` instead so that its thread is suspended instead.
26
21
22
+
NOTE: Prior version 5.4, there was only one `timeout` option for both request and trigger messages, but in some use-case it is better to have different timeouts for those actions.
23
+
Therefore `requestTimeout` and `triggerTimeout` options have been introduced.
24
+
27
25
The `requires-reply` property determines the action to take if the suspended thread times out before the trigger message arrives.
28
-
By default, it is `false`, which means the endpoint returns `null`, the flow ends, and the thread returns to the
29
-
caller.
26
+
By default, it is `false`, which means the endpoint returns `null`, the flow ends, and the thread returns to the caller.
30
27
When `true`, a `ReplyRequiredException` is thrown.
31
28
32
29
You can call the `trigger()` method programmatically (obtain the bean reference by using the name, `barrier.handler` -- where `barrier` is the bean name of the barrier endpoint).
0 commit comments