camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CamelBumper01 <bret...@yahoo.com>
Subject Re: wireTaps really asynchronous?
Date Thu, 11 Aug 2011 15:18:09 GMT
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.

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: http://camel.465427.n5.nabble.com/wireTaps-really-asynchronous-tp4648387p4689845.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Mime
View raw message