Just to add yet another layer of clarity (I hope this is helping...)
lock.lock();
try {
doAggregation(key, copy);
} finally {
lock.unlock();
}
Taking a *very* simplistic view, doAggregation() does two things:
1. combine messages together into an aggregated message, interact with
aggregation repo etc.
2. if "complete", send the aggregated message to the downstream processor.
If we were call these tasks "performAggregation()" and "sendDownstream()"
then all I'm suggesting is that a refactoring in the following direction
seems like it would make far more sense:
lock.lock();
try {
performAggregation(key, copy);
} finally {
lock.unlock();
}
if(completed) {
sendDownstream(...);
}
sendDownstream() would use the existing code to submit to an
executorService, which would be synchronous by default still. That way,
behaviour is unchanged except that *downstream processing no longer happens
inside the lock*.
I'm not, of course suggesting it's this trivial, there are several
complications in getting to this - this is just an outline.
Thanks
Baris.
--
View this message in context:
http://camel.465427.n5.nabble.com/Aggregator-lock-tp5739692p5739771.html
Sent from the Camel - Users mailing list archive at Nabble.com.
