...
![]() Info |
|
|
| 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
![]() Wiki Markup |
{div:class=confluenceTableSmall}
|| 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 {{ref}}. |
| {{executorServiceRef}} | | Reference identifier of a custom [Thread Pool|Threading Model] 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. |
{div}
|
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.
...
Wire Tap 