Versions Compared

Old Version 31

changes.mady.by.user Claus Ibsen

Saved on

compared with

New Version 32

changes.mady.by.user Claus Ibsen

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

In Camel 2.0 the threads DSL replaces the old thread DSL.

Camel 2.0 to 2.3 behavior

The threads DSL leverages the JDK concurrency framework for multi threading. It can be used to turn a synchronous route into Async. What happens is that from the point forwards from threads the messages is routed asynchronous in a new thread. The caller will either wait for a reply if a reply is expected, such as when we use Request Reply messaging. Or the caller will complete as well if no reply was expected such as Request Only messaging.

Camel 2.4 onwards behavior

The threads DSL leverages the JDK concurrency framework for multi threading. It can be used to turn a synchronous route into Async. What happens is that from the point forwards from threads the messages is routed asynchronous in a new thread. Camel leverages the asynchronous routing engine, which was re-introduced in Camel 2.4, to continue routing the Exchange asynchronously.

The threads DSL supports the following options:

Option

Description

poolSize

A number to indicate the core pool size of the underlying Java ExecutorService that is actually doing all the heavy lifting of handling Async tasks and correlate replies etc. By default a pool size of 10 is used.

executorService

You can provide a custom ExecutorService to use, for instance in a managed environment a J2EE container could provide this service so all thread pools is controlled by the J2EE container.

waitForTaskToComplete

@deprecated (removed in Camel 2.4): Option to specify if the caller should wait for the async task to be complete or not before continuing. The following 3 options is supported: Always, Never or IfReplyExpected. The first two options is self explained. The last will only wait if the message is Request Reply based. The default option is IfReplyExpected.

...

Warning
titleTransactions and threads DSL

Mind that when using transactions its often required that the Exchange is processed entirely in the same thread, as the transaction manager often uses ThreadLocal to store the intermediate transaction status. For instance Spring Transaction does this. So when using threads DSL the Exchange that is processed in the async thread cannot participate in the same transaction as the caller thread.

Notice: This does not apply to the ProducerTemplate Async API as such as the client usually does not participate in a transaction. So you can still use the Camel Client Async API and do async messaging where the processing of the Exchange is still handled within transaction. Its only the client that submitted the Exchange that does not participate in the same transaction.

See Also