INT-4091: Aggregator: Removal for Empty Groups
JIRA: https://jira.spring.io/browse/INT-4091 When `empty-group-min-timeout` is configured and `expireGroupsUponCompletion == false` and normal or partial sequences group release happens, schedule the group for removal after `empty-group-min-timeout`, since it is empty already. That lets to avoid `MessageGroupStoreReaper` configuration just for cleaning empty groups. * Retrieve the group `lastModified` to check if group is still valid for removal * Remove `ScheduledFeature` in the remove task * Polishing for debug messages to reflect the current logic * Reschedule empty group removal task in case of `InterruptedException` on the `lock.lockInterruptibly()` * Fix typos in docs Fix race condition between `groupStore.expireMessageGroups()`and `TaskScheduler` in the `AbstractCorrelatingMessageHandlerTests.testReaperReapsAnEmptyGroupAfterConfiguredDelay()` Also check groupSize for removal decision Address PR comments
This commit is contained in:
committed by
Gary Russell
parent
9ae8f329d7
commit
2f0b377cfb
@@ -505,6 +505,9 @@ Since _version 4.1_, you can now control this behavior using `expire-groups-upon
|
||||
NOTE: When a group is timed out, the `ReleaseStrategy` is given one more opportunity to release the group; if it does so, and `expire-groups-upon-timeout` is false, then expiration is controlled by `expire-groups-upon-completion`.
|
||||
If the group is not released by the release strategy during timeout, then the expiration is controlled by the `expire-groups-upon-timeout`.
|
||||
Timed-out groups are either discarded, or a partial release occurs (based on `send-partial-result-on-expiry`).
|
||||
|
||||
Starting with _version 5.0_ empty groups are also scheduled for removal after `empty-group-min-timeout`.
|
||||
If `expireGroupsUponCompletion == false` and `minimumTimeoutForEmptyGroups > 0`, the task to remove the group is scheduled, when normal or partial sequences release happens.
|
||||
=====
|
||||
|
||||
Using a `ref` attribute is generally recommended if a custom aggregator handler implementation may be referenced in other `<aggregator>` definitions.
|
||||
|
||||
@@ -161,6 +161,7 @@ Late arriving messages will be immediately discarded.
|
||||
Set this to `true` to remove the group completely; then, late arriving messages will start a new group and won't be discarded until the group again times out.
|
||||
The new group will never be released normally because of the "hole" in the sequence range that caused the timeout.
|
||||
Empty groups can be expired (completely removed) later using a `MessageGroupStoreReaper` together with the `empty-group-min-timeout` attribute.
|
||||
Starting with _version 5.0_ empty groups are also scheduled for removal after `empty-group-min-timeout`.
|
||||
Default: 'false'.
|
||||
|
||||
NOTE: Since there is no custom behavior to be implemented in Java classes for resequencers, there is no annotation support for it.
|
||||
|
||||
@@ -81,4 +81,5 @@ See <<http-header-mapping>> for more information.
|
||||
==== Aggregator Performance Changes
|
||||
|
||||
Aggregators now use a `SimpleSequenceSizeReleaseStrategy` by default, which is more efficient, especially with large groups.
|
||||
Empty groups are now scheduled for removal after `empty-group-min-timeout`.
|
||||
See <<aggregator>> for more information.
|
||||
|
||||
Reference in New Issue
Block a user