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, 14 Aug 2011 07:18:14 GMT
On Thu, Aug 11, 2011 at 5:18 PM, CamelBumper01 <> wrote:
> Hi Claus,
> Thanks for your response. I now understand why I was experiencing blocking.
> However, I would like to advocate that the default threadpool for wireTaps
> not use the  caller run rejection policy.  This default policy works well
> for splits and other mechanisms, but I don't believe it is useful for
> wireTaps as indicated by the situation I ran into.
> I would like to suggest that the wireTap run policy use the DiscardPolicy by
> default.  My rationale for this request is that a wireTap by definition
> should be non-intrusive (if you are modelling it after a traditional
> telephony wireTap paradigm).  Therefore, using the camel default caller run
> rejection policy for wireTaps by it's nature implies an intrusive wireTap.
> The DiscardPolicy would return the wireTap to a non-intrusive and truly
> asynchronous metaphor.

Some people uses the wireTap to spawn a new thread to route a copy of
the message etc.
Or a new message etc.

So they most likely dont want to discard old messages etc.

At first I would like to add some notes the the wire tap EIP about the
current defaults.
And how people can adjust this and chose their strategy. We may want
to make configuring the rejectionPolicy a tad easier on the wireTap so
you dont have to refer to a new thread pool or thread pool policy for

> As always, someone who wants to override this new default behavior may
> always do so.  Reasonable request?  Anyone else support or object?  How bout
> Camel 2.9 :-)
> 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