query regarding .MessageGroupStoreReaper...

[SARAL SAXENA]

Hi,

I was going on through the official manual of spring integration with context to aggregator and I also go through the topics of message store and .MessageGroupStoreReaper, please if you guys could explain a little about .MessageGroupStoreReaper also as I was not able to grasp that much about message reaper specially what advantage do it offer over message group store..? Thanks in advance..!!

[Gary Russell]

Let's say your group size is 10 and only 9 messages show up.

The aggregator release policy will never fire and the 9 messages will be stuck.

The aggregator has an attribute 'send-partial-result-on-expiry'.

If this is true, and "somebody" expires the group, then the partial group is sent to the output-channel.

The question is "who expires the group?". The aggregator is a passive component and, normally, only takes action when a message arrives.

Here's where the MessageGroupStoreReaper comes in. When scheduled to run, he simply expires any "old" groups.

If send-partial-groups-on-expiry is true, the "stuck" messages are sent to the output-channel; otherwise they are sent to the discard-channel.

HTH

[SARAL SAXENA]

Let's say your group size is 10 and only 9 messages show up.

The aggregator release policy will never fire and the 9 messages will be stuck.

The aggregator has an attribute 'send-partial-result-on-expiry'.

If this is true, and "somebody" expires the group, then the partial group is sent to the output-channel.

The question is "who expires the group?". The aggregator is a passive component and, normally, only takes action when a message arrives.

Here's where the MessageGroupStoreReaper comes in. When scheduled to run, he simply expires any "old" groups.

If send-partial-groups-on-expiry is true, the "stuck" messages are sent to the output-channel; otherwise they are sent to the discard-channel.

HTH

Hi Gary,

thanx a lot !!! amazing explanation it helps me a lot in understanding..!!I just want to know suppose if 20 messages are coming from a channel and aggregator is aggregating them and making them as a single complete message based on corelation startergy and then finally sending them to the destination channel based on release stratergy , but suppose imagine a situation let say when 18 messages are coming then in this case what an aggregator will do since it is expecting 20 messages as usual but this time it get's 18 messages , so will in this case MessageGroupStoreReaper will come into picture..or any other component will fit in this situation..!please advise ..!!

[Gary Russell]

That's what I just said, except I used 10 and 9 instead of your 20 and 18. So yes, that's what the reaper is for.

Just be sure to set the reaper timeout long enough to allow the normal processing to occur - you don't want to expire the group too early.

[SARAL SAXENA]

thanks Gary ..for the explanation..!!

[ray.frid]

Hi I read your great. explanation.

If the messageStoreReaper has timeout build in why I saw examples using task:scheduler? what is the relation between them why task:scheduler is Necessary here?

for example:


<bean id="messageStoreReaper"
class="org.springframework.integration.store.Messa geGroupStoreReaper">
<property name="messageGroupStore" ref="messageStore" />
<property name="timeout" value="4000" />
</bean>

<task:scheduler id="reaperScheduler" />
<task:scheduled-tasks scheduler="reaperScheduler">
<task:scheduled ref="messageStoreReaper" method="run"
fixed-rate="4000" />
</task:scheduled-tasks>

thanks,
ray.

[Gary Russell]

Please use [ code ]...[ /code ] tags when posting code and config (no spaces in brackets).

Well, unless a <bean/> manages its own Threads, it is a totally passive object (a "bean"), and won't "do" anything until something calls it. That's where the task scheduler comes in. In your case, it "runs" the reaper every 4 seconds and the reaper will expire any groups at least 4 seconds old.

However, normally, you would want to schedule the reaper more often than than it's timeout.

Let's take your example config.

Scheduler runs at 00:00:00 and there's nothing to expire.
A message arrives at a group at 00:00:01
Scheduler runs at 00:00:04 and there's still nothing to expire (the group is only 3 seconds old).
Scheduler runs at 00:00:08 and the group is expired.

Note that it takes 7 seconds to expire the group.

In practice, if the scheduler runs every n seconds and the reaper expires groups older than m seconds, the actual group exipiry will average somewhere between m and m+n seconds.

For large n (in relation to m), the average expiry time will trend towards n; for small n (in relation to m), the average will trend towards m.

For this reason it's usually not a good idea to have n larger than m and, generally, it would be some fraction of m.

In your case, if you set the scheduler to run every 1000 milliseconds, your groups will expire between 4 and 5 seconds.

If you set it to 100, your groups will expire between 4 and 4.1 seconds.

So, it really depends on the needs of your application how you set these parameters.

I hope that helps.

[ray.frid]

It did. thanks.