Question on Threads XML-DSL
Hi, I experimented with the Threads XML-DSL and found its behaviour to be somewhat confusing. These route elements - - 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 block is also done in the thread-pool thread. (In that sense there seems to be no point in having a " .. " block element; a single would look more appropriate.) Or is there a way for the route processing *after* the 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 component? What happened to the "waitForTaskToComplete" option? TIA, Carsten
Re: Question on Threads XML-DSL
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 wrote: > Hi, > > I experimented with the Threads XML-DSL and found its behaviour to be > somewhat confusing. > > These route elements > - > > > > > > > - > 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 block is also > done in the thread-pool thread. > (In that sense there seems to be no point in having a " .. > " block element; a single would look more > appropriate.) > > Or is there a way for the route processing *after* the 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 component? > What happened to the "waitForTaskToComplete" option? > > TIA, > Carsten -- Claus Ibsen - Red Hat, Inc. Email: cib...@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/
Re: Question on Threads XML-DSL
Thanks for pointing to the wiretap component. Our use case was a where each loop run should be processed in parallel. First we were using a seda endpoint (with concurrentConsumers>1) but 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 wrote: Hi, I experimented with the Threads XML-DSL and found its behaviour to be somewhat confusing. These route elements - - 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 block is also done in the thread-pool thread. (In that sense there seems to be no point in having a " .. " block element; a single would look more appropriate.) Or is there a way for the route processing *after* the 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 component? What happened to the "waitForTaskToComplete" option? TIA, Carsten
