1

This is a general question of how to release the resources used in ReleaseStrategy. I'm referring to the response submitted here for example - I was wondering what is the recommended strategy for cleaning the map used in the example if something went wrong:

private final Map<Object, AtomicInteger>() map = new HashMap<>();

Use case: 990 out of 1000 group messages (or 9 out of 10 as in the referred example) were received but then a timeout elapsed (we are not interested in partial result)... How would you clean the map values for this particular groupId or in general: what would be the best approach to release any other resources used in ReleaseStrategy?

I was thinking of some expiring maps or maybe triggering bean cleanUp method from the outside... But maybe there is some suggested way to handle these cases?

Maybe I'm not getting how exactly ReleaseStrategy works in case of groupTimeout, so I have the below example config:

group-timeout="1000" discard-channel="discardChannel" 
end-partial-result-on-expiry="false" release-strategy="xxx"

Let say I have a group of 10 messages produced by the splitter, each message is really some job to be accomplished by the thread pool executor. So if any (let say the second job) of the jobs execution pool takes longer than the specified group-timeout, this particular message will be send to the discardChannel but the ReleaseStrategy will be called as well, right?

But in such a case do I still get the MessageGroup updated within that discarded message? I assume not - so the canRelease method invocation can be greater than the group.getMessages().size(), right?

What is happening now? What with this one message that was received before the timeout elapsed? Is this the situation that I still can decide if I want to release this one message that is within the MessageGroup? What with 8 remaining messages (jobs), do they belong to the new groupId after the second message from the group was discarded (I assume that expire-groups-upon-timeout is set to true by default), so do these 8 messages get a new groupId and are being sent to ReleaseStrategy as well?

Other question is what will happen when canRelease method returns only false (having the above configuration) - I've noticed that although I'm getting the info like below:

Expiring MessageGroup with correlationKey[36293c73-6f66-4a1a-8824-9d5268e07081]
Expiring MessageGroup with correlationKey[36293c73-6f66-4a1a-8824-9d5268e07081]

messages are "being returned" to the ServiceActivator (jobs executor pool bean) in such a case? So it is executed again and again in such cases so I cannot exit the workflow?

Community
  • 1
  • 1
m52509791
  • 449
  • 5
  • 13

1 Answers1

1

Typically, I would include some kind of timestamp in the map contents and have some task scheduled to clean it up every so often.

EDIT

The release strategy is called whenever a new message arrives and has been added to the group. If the group is not released and is timed out, the release strategy is called one more time, so it can decide whether or not to release the group. If it does, this is the same as not releasing the group with sendPartialGroupOnExpiry true. If it returns false (on the timeout), the group is either discarded or released, based on sendPartialGroupOnExpiry.

expireGroupsUponTimeout is true by default, which means late messages will form a new group and the release strategy will be invoked for each message. Set it to false if you wish to discard late messages; the group is retained (with zero messages) so we know that we need to discard late arrivers.

In this case, the release strategy will not be called for the late messages, they are immediately discarded.

You can easily clean up the state on timeout by checking the size of the group - if it's the same as last time, then the group is being expired.

For a long-running system, you might want to expire empty groups, eventually, using a message group store reaper.

Gary Russell
  • 166,535
  • 14
  • 146
  • 179
  • You mean separated scheduler? So I assume there is no physical possibility to combine this action somehow with the scheduler aggregator attribute which is being triggered on groupTimeout (our use case)? – m52509791 Nov 16 '15 at 15:20
  • Well, the release strategy is called one more time on the group timeout thread (although the release strategy doesn't know that). So, I suppose you could check the time at that time). If the strategy returns true, the group will be released normally. I suppose you could use a custom task scheduler and check the thread name - a bit klunky but it would work. – Gary Russell Nov 16 '15 at 15:27
  • If release strategy is called one more time can I rely on canRelease method invocation count as in the referred example? – m52509791 Nov 16 '15 at 16:50
  • I am not sure what you mean by "rely". The release strategy is invoked when a new message arrives and when the group is timed out. The latter is intended to give the strategy the opportunity to release the group normally after the timeout (effectively the same as send partial group on expiry). So you can compare the size of the group on each call and if it's the same size as last time, it means it is being timed out. – Gary Russell Nov 16 '15 at 17:07
  • I updated the question to include group-timeout concerns and continue the discussion with Gary. – m52509791 Nov 16 '15 at 19:17
  • I edited my answer with further clarification about how the aggregator works. – Gary Russell Nov 16 '15 at 20:16
  • Thanks for the clarification. But why the execution is being pushed back to the job running before aggregator (ServiceActivator) in case of continuous return false from canRelease method? – m52509791 Nov 16 '15 at 20:25
  • I don't understand what you mean by "pushed back". – Gary Russell Nov 16 '15 at 20:27
  • I mean it is being re executed somehow. – m52509791 Nov 16 '15 at 20:29
  • That must be something else; it's not related to aggregator - you need to show the pertinent parts of your configuration. – Gary Russell Nov 16 '15 at 20:40
  • Of course, you are right - that was a configuration mismatch... I accepted your answer, thanks! – m52509791 Nov 16 '15 at 21:02