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:
Artem Bilan
2016-10-31 13:34:41 -04:00
committed by Gary Russell
parent 9ae8f329d7
commit 2f0b377cfb
7 changed files with 141 additions and 22 deletions

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.