camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: wireTaps really asynchronous?
Date Sun, 31 Jul 2011 10:52:39 GMT

Yes its really asynchronous. The problem you face could be the fact
the thread pool gets filled up with tasks, and then the default
behavior is to use the caller run rejection policy of the thread pool.

You can customize the thread pool on the wire tap to use a different
strategy if you like

See more here

On Fri, Jul 29, 2011 at 11:21 PM, CamelBumper01 <> wrote:
> I have a wireTap in a route (route A) and the wireTap creates a new message
> and is directed to a new route (route B).
>     A -> WT -> to(dest)              |
>             \/
>              B
>     B -> to(jms:queue:output)  -each thread in the pool with hang if the
> jms queue is full
> If B is publishing to a JMS Queue that fills up and blocks (as is the case
> with Activemq by default) then it appears that after the thread pool that is
> used by the wireTap is exhausted (due to jms hangs), then route A will hang.
> I would think that you would want to bypass the wiretap at this point as it
> is a liability and not impact route A.
> So, how is the executor being called in a route with a wireTap and should
> the wireTap be avoided when the wireTap thread pool is exhausted?
> Thanks,
> Bret
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message