You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Bernard Ligny <be...@gmail.com> on 2013/08/02 15:51:34 UTC
Risk of JMS flooding with long-lasted redelivery policy ?
Can someone please confirm what my colleague has observed on our project (NB:
We use Camel 2.8.5).
Let us take for instance:
- a JMS consumer (with a particular value of "maxConcurrentConsumers")
- a (non transacted) error handler with the following redelivery policy:
* a large number of retries (ex: 20)
* a significant amount of times between 2 attempts (ex: 5 sec)
* useExponentialBackOff=true + backOffMultiplier
So, in the worst situation, the complete retry process (for a single
exchange) will take a very a long time:
20 attempts x (at least 5) sec = more than 100 sec
During the time (>100 sec) Camel is busy with the processing of this single
exchange, we may of course receive many items in the JMS queue.
What we have observed, is that the JMS consumer is staying busy and does NOT
release its jms session until a successful attempt. In my example, a jms
consumer will hold the connection for 100 sec, even while sleeping between 2
attempts ! Needless to say that, in case of "burst" on the producer side,
there could be rapidly no more enough free consumers...
I do not understand why (in a non transacted route) Camel does not
immediately release its jms session.
Is it a wanted behaviour (and also a good practice) to keep holding the JMS
connection till the end of the processing of the exchange ?
If we decide for instance to wait 60 sec between 2 attempts, I would like
for instance to pause/free my jms consumer so that he can serve other
potential messages present in my queue.
--
View this message in context: http://camel.465427.n5.nabble.com/Risk-of-JMS-flooding-with-long-lasted-redelivery-policy-tp5736707.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Risk of JMS flooding with long-lasted redelivery policy ?
Posted by Bernard Ligny <be...@gmail.com>.
Thanks Clause.
Unfortunately, as i said, we use Camel v2.8.5 on our project, and
"asyncConsumer" was introduced in Camel 2.9 :-(
Do yo see a(nother) possible solution or workaround that could be applied in
Camel 2.8.5 ?
Bernard.
--
View this message in context: http://camel.465427.n5.nabble.com/Risk-of-JMS-flooding-with-long-lasting-redelivery-policy-tp5736707p5736786.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Risk of JMS flooding with long-lasted redelivery policy ?
Posted by Claus Ibsen <cl...@gmail.com>.
Use async delayed in the error handler / onException. And also
asyncConsumer=true on the jms consumer.
On Fri, Aug 2, 2013 at 3:51 PM, Bernard Ligny <be...@gmail.com> wrote:
> Can someone please confirm what my colleague has observed on our project (NB:
> We use Camel 2.8.5).
>
> Let us take for instance:
> - a JMS consumer (with a particular value of "maxConcurrentConsumers")
> - a (non transacted) error handler with the following redelivery policy:
> * a large number of retries (ex: 20)
> * a significant amount of times between 2 attempts (ex: 5 sec)
> * useExponentialBackOff=true + backOffMultiplier
>
> So, in the worst situation, the complete retry process (for a single
> exchange) will take a very a long time:
> 20 attempts x (at least 5) sec = more than 100 sec
>
> During the time (>100 sec) Camel is busy with the processing of this single
> exchange, we may of course receive many items in the JMS queue.
>
> What we have observed, is that the JMS consumer is staying busy and does NOT
> release its jms session until a successful attempt. In my example, a jms
> consumer will hold the connection for 100 sec, even while sleeping between 2
> attempts ! Needless to say that, in case of "burst" on the producer side,
> there could be rapidly no more enough free consumers...
>
> I do not understand why (in a non transacted route) Camel does not
> immediately release its jms session.
> Is it a wanted behaviour (and also a good practice) to keep holding the JMS
> connection till the end of the processing of the exchange ?
> If we decide for instance to wait 60 sec between 2 attempts, I would like
> for instance to pause/free my jms consumer so that he can serve other
> potential messages present in my queue.
>
>
>
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Risk-of-JMS-flooding-with-long-lasted-redelivery-policy-tp5736707.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
Email: cibsen@redhat.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen