Hi
Yeah the sending to the thread pool could potential happen outside the
lock. I have logged a ticket
https://issues.apache.org/jira/browse/CAMEL-6775
It does complicated it a bit in the logic as there is potential also
timeout and recovery tasks that operate as well.
On Wed, Sep 18, 2013 at 7:37 PM, bacar <ba...@acar.org.uk> wrote:
> 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.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cib...@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
