camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Baris Acar <ba...@acar.org.uk>
Subject Re: Aggregator lock
Date Mon, 23 Sep 2013 07:35:28 GMT
Great, thanks Claus. I've attached a trivial unit test to the Jira issue showing behaviour
that should pass following the fix, which you're welcome to include/adapt if it's useful.


Barış

> On 21 Sep 2013, at 11:34, Claus Ibsen <claus.ibsen@gmail.com> wrote:
> 
> 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 <baris@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: cibsen@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen

Mime
View raw message