You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by CamelBumper01 <br...@yahoo.com> on 2011/08/11 17:18:09 UTC
Re: wireTaps really asynchronous?
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.
Re: wireTaps really asynchronous?
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Aug 14, 2011 at 9:18 AM, Claus Ibsen <cl...@gmail.com> wrote:
> On Thu, Aug 11, 2011 at 5:18 PM, CamelBumper01 <br...@yahoo.com> 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
> that.
>
I have added a note to the Camel wiki page, that the wire tap uses the
default thread pool settings.
And that you must configure it explicit if you need to eg, discard old
messages etc, in case the pool is exhausted.
>
>> 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.
>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: wireTaps really asynchronous?
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Aug 11, 2011 at 5:18 PM, CamelBumper01 <br...@yahoo.com> 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
that.
> 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.
>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/