camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Risk of JMS flooding with long-lasted redelivery policy ?
Date Mon, 05 Aug 2013 08:36:58 GMT
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 <bernard.ligny@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

Mime
View raw message