Thanks for pointing to the wiretap component.
Our use case was a <loop> where each loop run should be processed in
parallel.
First we were using a seda endpoint (with concurrentConsumers>1) but
<wiretap> with its thread pool (and no extra queue in between) proved to
be the better solution here.
Am 04.05.2015 um 14:16 schrieb Claus Ibsen:
Hi
Its like the consumer of the route being fully async so it releases
its thread at threads, and then it takes over routing.
If you want to fork off work, then use wire tap to decouple the work
from the current routing.
On Mon, May 4, 2015 at 11:48 AM, Carsten Lohmann <[email protected]> wrote:
Hi,
I experimented with the Threads XML-DSL and found its behaviour to be somewhat
confusing.
These route elements
---------------------
<setExchangePattern pattern="InOnly"/>
<log message="BEFORE Threads block; ThreadName: '${threadName}'"/>
<threads poolSize="10">
<log message="INSIDE Threads block; ThreadName: '${threadName}'"/>
</threads>
<log message="AFTER Threads block; ThreadName: '${threadName}'"/>
---------------------
produce this output
---------------------
INFO BEFORE Threads block; ThreadName: 'default-workqueue-1'
INFO INSIDE Threads block; ThreadName: 'Camel (test) thread #10 - Threads'
INFO AFTER Threads block; ThreadName: 'Camel (test) thread #10 - Threads'
---------------------
It seems strange that route processing *after* the <threads> block is also done
in the thread-pool thread.
(In that sense there seems to be no point in having a "<threads> .. </threads>" block element;
a single <threads poolSize="10"/> would look more appropriate.)
Or is there a way for the route processing *after* the <threads> block to be done in the
same thread as *before*? (I already made sure the exchange pattern was "InOnly".)
I wanted to do some work in a separate thread (not wanting to wait for its
result) and in the meantime continue with the main thread.
Is that possible with the <threads> component?
What happened to the "waitForTaskToComplete" option?
TIA,
Carsten
