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 Wed, 18 Sep 2013 16:32:25 GMT
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 around all downstream processing without detailed inspection of the source. 

Here's an extreme example to illustrate what I mean:

from("direct:a")
  .threads(5)       // set up a thread pool
  .bean(dostuff)    // excellent, stuff is done in parallel on 5 threads - happy days.
  .aggregate(...)   // I'm a good dev and remembered to RE-introduce a threadpool using executorService,
otherwise camel will not execute any of the following in the thread pool I made above. 
    .executorService(...)
  .multicast(...)   // does multicast() acquire a big lock on downstream work just like aggregate?
    .executorService(...)  // (...better process downstream on another executor service to
be sure)
  .delay(1000)      // maybe delay will lock too? Add another executorService!
    .executorService(...)
  .log("got a msg") // how about now? Maybe log() locks all downstream threads too just like
aggregate! Who knows?
    .threads(5)     // shall I just reintroduce the threadpool on every other line, just to
be absolutely sure?
  .someOtherBuiltInCamelProcessor()
    .threads(5)     // ... if not, how can I know *when* I need to reintroduce it? Camel may
arbitrarily lock me out!
  // etc

How can I reason about my system's behaviour without knowing which parts of my code will be
executed under a seemingly arbitrary mutual exclusion lock? Which processors take this lock,
and why?

Again, thanks for your time. 

Barış
Mime
View raw message