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/07/29 23:21:59 UTC
wireTaps really asynchronous?
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: http://camel.465427.n5.nabble.com/wireTaps-really-asynchronous-tp4648387p4648387.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/
Re: wireTaps really asynchronous?
Posted by CamelBumper01 <br...@yahoo.com>.
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>.
Hi
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
http://camel.apache.org/threading-model.html
On Fri, Jul 29, 2011 at 11:21 PM, CamelBumper01 <br...@yahoo.com> 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: http://camel.465427.n5.nabble.com/wireTaps-really-asynchronous-tp4648387p4648387.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/