You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Carsten Lohmann <c_...@gmx.net> on 2015/05/04 11:48:59 UTC
Question on Threads XML-DSL
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
Re: Question on Threads XML-DSL
Posted by Carsten Lohmann <ca...@gmx.de>.
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 <c_...@gmx.net> 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
>
>
>
Re: Question on Threads XML-DSL
Posted by Claus Ibsen <cl...@gmail.com>.
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 <c_...@gmx.net> 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
--
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
hawtio: http://hawt.io/
fabric8: http://fabric8.io/