Aggregator MessageStore

[stuartd]

I am using SI v1, and have the following scenario:

I receive a message then split it into 2, and send it to an external system via JMS. I expect to receive 2 replies via another JMS queue, which I will aggregate into a single message, and send back to the source.

This seems like a task fit for the aggregator component. The process also needs to be reliable, such that if I receive one of the replies before the aggregator is complete, and then then the system stops working, I need to be able to recover properly when the system restarts. This implies that I need to use a persistant message store for the aggregator, but from what I can tell the v1 aggregator only supports an in-memory message store that cant easily be swapped out. I have seen this Jira issue https://jira.springsource.org/browse...ream-issue-tab which says that this has been resolved in M3 of v2.

My question is, do I need to upgrade to version 2 to be able to have an aggregator that is crash resilient, or is there some way to make this scenario work in v1?

[iwein]

Persistent storage underneath the aggregator is not supported in 1.0.x. However, you can usually get away with a custom solution that is only deleting the original of the incoming messages when the aggregation is complete.

[stuartd]

Thanks for the reply Iwein. So sounds like my best option will be to persist the messages to a DB before sending on to the aggregator, and then delete after aggregation is complete. Will just have to be very careful with the transaction boundaries...

[iwein]

Indeed, that would probably be your best bet. Since processing will happen in a different thread than sending, you should not rely on a single transaction the states are something like:

todo -> aggregating -> done

After a crash you reprocess everything in state aggregating. If ordering is of no concern you can implement an idempotent receiver after the aggregator and periodically retry all aggregating messages, this will also help if you want to scale out later.