Re: Aggregator lock

2013-09-23 Thread bacar
into small groups. However I'll definitely profile it / compare it to the other workaround of introducing a thread pool. -- View this message in context: http://camel.465427.n5.nabble.com/Aggregator-lock-tp5739692p5740053.html Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Aggregator lock

2013-09-23 Thread Claus Ibsen
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. >> >>

Re: Aggregator lock

2013-09-23 Thread Baris Acar
>> 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 no

Re: Aggregator lock

2013-09-21 Thread Claus Ibsen
s 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 &

Re: Aggregator lock

2013-09-18 Thread bacar
ing 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.

Re: Aggregator lock

2013-09-18 Thread Baris Acar
Thanks Claus. It is still verbose/error prone - I have to repeat it every time I use such a processor (verbose) and I have to remember to do it (error prone). And that assumes I *know* that I have to do it in the first place - I don't know how I can tell whether a given processor holds a lock ar

Re: Aggregator lock

2013-09-18 Thread Claus Ibsen
message that completes an >>>> aggregation, that downstream processing will continue on that consumer >>>> thread, whilst other such downstream processing for another 'completed >>>> aggregation' message may be happening in parallel on the other SEDA >>>&g

Re: Aggregator lock

2013-09-18 Thread Baris Acar
;> >> What I'm finding instead is that whilst all of the work downstream of >> aggregate() does occur across the two consumer threads, it is serialised; >> no two threads execute the processors at the same time. This becomes quite >> noticeable if this downstream wor

Re: Aggregator lock

2013-09-18 Thread Claus Ibsen
; message may be happening in parallel on the other SEDA >>> consumer thread. >>> >>> What I'm finding instead is that whilst all of the work downstream of >>> aggregate() does occur across the two consumer threads, it is serialised; >>> no two threads

Re: Aggregator lock

2013-09-18 Thread Claus Ibsen
umer threads, it is serialised; > no two threads execute the processors at the same time. This becomes quite > noticeable if this downstream work is lengthy. I've uploaded a sample to > https://github.com/bacar/aggregator-lock, which you can run with mvn test > -Dtest=AggregateLock.

Aggregator lock

2013-09-17 Thread Baris Acar
oss the two consumer threads, it is serialised; no two threads execute the processors at the same time. This becomes quite noticeable if this downstream work is lengthy. I've uploaded a sample to https://github.com/bacar/aggregator-lock, which you can run with mvn test -Dtest=AggregateLock