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

Usage clarification of the group-timeout property

Browse Source 
Added some clarification on the usage of  the group-timeout property based on discussion 
https://stackoverflow.com/questions/48230453/issue-with-spring-integration-aggregator-group-timeout-value

* Update aggregator.adoc

Fixed according to one sentence per line rule.
This commit is contained in:
Mike Gorodilin
2019-08-20 14:07:18 +00:00
committed by Artem Bilan
parent 8d1d0eca28
commit f0807fe704
1 changed files with 5 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
src/reference/asciidoc/aggregator.adoc
View File

@@ -470,7 +470,8 @@ By default, an internal `DefaultLockRegistry` is used.
Use of a distributed `LockRegistry`, such as the `ZookeeperLockRegistry`, ensures only one instance of the aggregator can operate on a group concurrently.
See <<./redis.adoc#redis-lock-registry,Redis Lock Registry>>, <<./gemfire.adoc#gemfire-lock-registry,Gemfire Lock Registry>>, and <<./zookeeper.adoc#zk-lock-registry,Zookeeper Lock Registry>> for more information.
<21> A timeout (in milliseconds) to force the `MessageGroup` complete when the `ReleaseStrategy` does not release the group when the current message arrives.
This attribute provides a built-in time-based release strategy for the aggregator when there is a need to emit a partial result (or discard the group) if a new message does not arrive for the `MessageGroup` within the timeout.
This attribute provides a built-in time-based release strategy for the aggregator when there is a need to emit a partial result (or discard the group) if a new message does not arrive for the `MessageGroup` within the timeout which counts from the time the last message arrived.
To set up a timeout which counts from the time the `MessageGroup` was created see `group-timeout-expression` information.
When a new message arrives at the aggregator, any existing `ScheduledFuture<?>` for its `MessageGroup` is canceled.
If the `ReleaseStrategy` returns `false` (meaning do not release) and `groupTimeout > 0`, a new task is scheduled to expire the group.
We do not advise setting this attribute to zero (or a negative value).
@@ -485,7 +486,9 @@ Used for scheduling the `MessageGroup` to be forced complete.
If the expression evaluates to `null`, the completion is not scheduled.
If it evaluates to zero, the group is completed immediately on the current thread.
In effect, this provides a dynamic `group-timeout` property.
See `group-timeout` for more information.
As an example, if you wish to forcibly complete a `MessageGroup` after 10 seconds have elapsed since the time the group was created you might consider using the following SpEL expression: `timestamp + 10000 - T(System).currentTimeMillis()` where `timestamp` is provided by `MessageGroup.getTimestamp()` as the `MessageGroup` here is the `#root` evaluation context object.
Bear in mind however that the group creation time might differ from the time of the first arrived message depending on other group expiration properties' configuration.
See `group-timeout` for more information.
Mutually exclusive with 'group-timeout' attribute.
<23> When a group is completed due to a timeout (or by a `MessageGroupStoreReaper`), the group is expired (completely removed) by default.
Late arriving messages start a new group.