WireTap thread pool
The Wire Tap uses a thread pool to process the tapped messages. This thread pool will by default use the settings detailed at Threading Model. In particular, when the pool is exhausted (with all threads utilized), further wiretaps will be executed synchronously by the calling thread. To remedy this, you can configure an explicit thread pool on the Wire Tap having either a different rejection policy, a larger worker queue, or more worker threads.
Camel's Wire Tap node supports two flavors when tapping an Exchange:
-With the traditional Wire Tap, Camel will copy the original Exchange and set its Exchange Pattern to InOnly, as we want the tapped Exchange to be sent in a fire and forget style. The tapped Exchange is then sent in a separate thread so it can run in parallel with the original. Beware that only the Exchange is copied - Wire Tap won't do a deep clone (unless you specify a custom processor via onPrepareRef which does that). So all copies could share objects from the original Exchange.
-Camel also provides an option of sending a new Exchange allowing you to populate it with new values.
Sending a copy (traditional wiretap)
Using the Fluent BuildersUsing the Spring XML Extensions
Sending a new Exchange
Using the Fluent Builders
From Camel 2.3 onwards the Expression or Processor is pre-populated with a copy of the original Exchange, which allows you to access the original message when you prepare a new Exchange to be sent. You can use the
Below is the processor variation. This example is from Camel 2.3, where we disable
The processor variation, which uses a processorRef attribute to refer to a Spring bean by ID: Here is the Expression variation, where the expression is defined in the body tag: This variation accesses the body of the original message and creates a new Exchange based on the Expression. It will create a new Exchange and have the body contain
For another example of this pattern, refer to the wire tap test case.
Using Dynamic Uris
Available as of Camel 2.16:
For example to wire tap to a dynamic uri, then it supports the same dynamic uris as documented in Message Endpoint. For example to wire tap to a JMS queue where the header ID is part of the queue name
Sending a new Exchange and set headers in DSL
Available as of Camel 2.8
If you send a new message using Wire Tap, then you could only set the message body using an Expression from the DSL. If you also need to set headers, you would have to use a Processor. In Camel 2.8 onwards, you can now set headers as well in the DSL.
The following example sends a new message which has
The XML DSL is slightly different than Java DSL in how you configure the message body and headers using <body> and <setHeader>:
Using onPrepare to execute custom logic when preparing messages
Available as of Camel 2.8
See details at Multicast
Using This Pattern
If you would like to use this EIP Pattern then please read the Getting Started, you may also find the Architecture useful particularly the description of Endpoint and URIs. Then you could try out some of the Examples first before trying this pattern out.