Skip to content

Memory leak in AbstractCorrelatingMessageHandler #3794

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
vfunshteyn-zw opened this issue May 9, 2022 · 0 comments · Fixed by #3796
Closed

Memory leak in AbstractCorrelatingMessageHandler #3794

vfunshteyn-zw opened this issue May 9, 2022 · 0 comments · Fixed by #3796

Comments

@vfunshteyn-zw
Copy link

In what version(s) of Spring Integration are you seeing this issue?
SI core 5.x

Describe the bug
Hard references to completed and released MessageGroup instances stored memory by AbstractCorrelatingMessageHandler

Additional details
Please see the following discussion: 2f0b377#r73229543, also note this is effectively a sibling of https://jira.spring.io/browse/INT-3999, the fix for which was never applied to the empty group removal logic.

@vfunshteyn-zw vfunshteyn-zw added status: waiting-for-triage The issue need to be evaluated and its future decided type: bug labels May 9, 2022
vfunshteyn-zw referenced this issue May 9, 2022
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
@artembilan artembilan added this to the 6.0 M3 milestone May 9, 2022
@artembilan artembilan added in: core backport 5.5.x and removed status: waiting-for-triage The issue need to be evaluated and its future decided labels May 9, 2022
artembilan added a commit to artembilan/spring-integration that referenced this issue May 10, 2022
Fixes spring-projects#3794

* Replace hard reference to message group with its `id` in the
`AbstractCorrelatingMessageHandler.removeEmptyGroupAfterTimeout()`
* Replace hard reference to message with its `id` in the
`DelayHandler.rescheduleAt()`

**Cherry-pick to `5.5.x`**
artembilan added a commit to artembilan/spring-integration that referenced this issue May 10, 2022
Fixes spring-projects#3794

* Replace hard reference to message group with its `id` in the
`AbstractCorrelatingMessageHandler.removeEmptyGroupAfterTimeout()`
* Replace hard reference to message with its `id` in the
`DelayHandler.rescheduleAt()`

**Cherry-pick to `5.5.x`**
garyrussell pushed a commit that referenced this issue May 10, 2022
Fixes #3794

* Replace hard reference to message group with its `id` in the
`AbstractCorrelatingMessageHandler.removeEmptyGroupAfterTimeout()`
* Replace hard reference to message with its `id` in the
`DelayHandler.rescheduleAt()`

**Cherry-pick to `5.5.x`**
garyrussell pushed a commit that referenced this issue May 10, 2022
Fixes #3794

* Replace hard reference to message group with its `id` in the
`AbstractCorrelatingMessageHandler.removeEmptyGroupAfterTimeout()`
* Replace hard reference to message with its `id` in the
`DelayHandler.rescheduleAt()`

**Cherry-pick to `5.5.x`**
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants