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.

Options

Name	Default Value	Description
`uri`		The URI of the endpoint to which the wire-tapped message will be sent. You should use either `uri` or `ref`.
`ref`		Reference identifier of the endpoint to which the wire-tapped message will be sent. You should use either `uri` or `re f`.
`executorServiceRef`		Reference identifier of a custom Thread Pool to use when processing the wire-tapped messages. If not set, Camel will use a default thread pool.
`processorRef`		Reference identifier of a custom Processor to use for creating a new message (e.g., the "send a new message" mode). See below.
`copy`	`true`	Camel 2.3: Whether to copy the Exchange before wire-tapping the message.
`onPrepareRef`		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.

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.

WireTap node

-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 paralle l with the original. Beware that only the Exchange is copied - Wire Tap won't do a deep clone. 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)

Options

Name	Default Value	Description
`uri`		The URI of the endpoint to which the wire-tapped message will be sent. You should use either `uri` or `ref`.
`ref`		Reference identifier of the endpoint to which the wire-tapped message will be sent. You should use either `uri` or `re f`.
`executorServiceRef`		Reference identifier of a custom Thread Pool to use when processing the wire-tapped messages. If not set, Camel will use a default thread pool.
`processorRef`		Reference identifier of a custom Processor to use for creating a new message (e.g., the "send a new message" mode). See below.
`copy`	`true`	Camel 2.3: Whether to copy the Exchange before wire-tapping the message.
`onPrepareRef`		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.

WireTap thread pool

WireTap node

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. Bewar e 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 Builders