Question on aggregator

[binz84]

Splitter -> Router -> Aggregator

In this config, say the router routes few messages to nullchannel. Would the aggregator be able to aggregate the remaining messages - or would it wait for the messages that have been dumped into null channel? (assume the aggregator used is the default aggregator provided by Spring)

[oleg.zhurakousky]

Yes you can do that easily but you have to configure it properly, and I actually covered this use case in the recent webinar which thankfully was recorded and you can see it here http://www.youtube.com/watch?v=RY6dN...1&feature=plcp
You can also look at the example directy here https://github.com/olegz/s12gx.2011/...egration/error

[oleg.zhurakousky]

And if you get this message on time you can attend the Part-2 of the webinar which will begin in 20 min https://vmwareevents.webex.com/mw030...vents%26%26%26 where i'll be discussing other advanced concepts.

[binz84]

Thanks Oleg for the invite, but I'm afraid I won't be able to make it now.

I just took a look at your github example. If I got it correctly, the errored out messages are redirected to a separate channel and then from there, they are fed back to the aggregator. But what if the error messages are dropped onto a nullchannel or are just logged into a log file. The aggregator would then won't receive those many messages as indicated by the sequence_size header. Correct? So in that case aggregator will have to wait until it times out.
I think I should change my design.

[oleg.zhurakousky]

Yes you got it right. By dropping the messages to a nullChannel you have no way of telling the aggregator that those messages are not coming. But by simply sending them to a separate channel which eventually loops back to the aggregator you essentially satisfying the aggregator's contract. It cost you nothing to do so and it does the job and in fact IMHO its more appropriate than dropping messages to a nullChannel since sooner or later you'll be asking how can i let the consumer know that out of 5 messages 3 were aggregated and 2 were dropped? The approach I am demonstrating allows exactly that and you can easily filter out later on the messages that are dropped.
And if you worry about the size of a dropped message (and that is the reason why you don't want to send it), you can always modify the dropped message into a 'poison message' which will have some simple description in the payload describing why it was dropped as long as it has the message headers relevant to the aggregator (e.g., correlationId, sequence* etc...) to satisfy its contract.

[binz84]

That makes sense. Thanks Oleg