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 -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
