Please forgive me, but I’m missing something. I understand that the behavior of the ZipAggregationStrategy in failure scenarios doesn’t work for you, but I don’t understand what the LevelDB persistent store brings to the table that would help.
It seems to me that both the ZipAggregrationStrategy and the LevelDB aggregation repository use the filesystem, so they’ll both be limited by the availability of the filesystem. I agree it would be nice if it could use a different aggregation repository - that would allow recovering on a different node which seems kinda nice. But it sounds like the ZipAggregationStrategy needs a better recovery mechanism - if it’s loosing messages in failure scenarios now, I don’t see how using a different aggregation repository would help. Can you please elaborate? > On May 12, 2016, at 12:24 PM, [email protected] wrote: > > > The file system isn't exactly a good persistent store in this case, as > Karlovsky Alexey pointed out it is not reliable. You will lose inflight > messages in memory when the route shuts down. I have to stop the channel on > the messaging system, make sure the tmp directory is empty and the current > completionInterval has finished before stopping the route. > > We can write our own, but wanted to reach out to see if anyone else had run > across this and solved it already. It would be a nice addition to the > ZipAggregationStrategy to use leveldb as persistent store but I wasn't able > to get it to work, yet... > > > > > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/ZipAggregationStrategy-with-persistent-store-tp5782458p5782503.html > Sent from the Camel - Users mailing list archive at Nabble.com.
