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ış
