Wire Tap (from the EIP patterns) allows you to route messages to a separate location while they are being forwarded to the ultimate destination.
If you Wire Tap a stream message body then you should consider enabling Stream caching to ensure the message body can be read at each endpoint. See more details at Stream caching.
Name | Default | Description |
---|---|---|
|
| Mandatory: The URI of the endpoint to which the wire-tapped message should be sent. From Camel 2.16: support for dynamic |
|
| Reference ID of a custom Thread Pool to use when processing the wire-tapped messages. When not set, Camel will use an instance of the default thread pool. |
|
| Reference ID of a custom Processor to use for creating a new message. See "Sending a New Exchange" below. |
|
| Camel 2.3: Whether to copy the Exchange before wire-tapping the message. |
|
| Camel 2.8: Reference identifier of a custom Processor to prepare the copy of the Exchange to be wire-tapped. This allows you to do any custom logic, such as deep-cloning the message payload. |
| Camel 2.16: Allows to configure the cache size for the Setting the value to | |
|
| Camel 2.16: Whether to ignore an endpoint URI that could not be resolved. When |
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:
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.Using the Fluent Builders
Using the Fluent Builders
Camel supports either a processor or an Expression to populate the new Exchange. Using a processor gives you full power over how the Exchange is populated as you can set properties, headers, etc. An Expression can only be used to set the IN
body.
From Camel 2.3: 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 copy
option (enabled by default) to indicate whether you want this. If you set copy=false
, then it works as in Camel 2.2 or older where the Exchange will be empty.
Below is the processor variation. This example is from Camel 2.3, where we disable copy
by passing in false
to create a new, empty Exchange.copy
=false
which results in the creation of a new, empty Exchange.
The processor variation, which uses a processorRef
attribute to refer to a Spring bean by ID:body
tag:"Bye ORIGINAL BODY MESSAGE HERE"
For another example of this pattern, refer to the wire tap test case.
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:
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. From Camel 2.8: it's possible to set headers as well using the DSL.
The following example sends a new message which has
Bye World
as message body.id
with the value 123
.date
which has current date as value.The XML DSL is slightly different than Java DSL in how you configure the message body and headers using <body>
and <setHeader>
:
onPrepare
to Execute Custom Logic when Preparing MessagesAvailable as of Camel 2.8
See details at Multicast