camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernard Ligny <bernard.li...@gmail.com>
Subject Risk of JMS flooding with long-lasted redelivery policy ?
Date Fri, 02 Aug 2013 13:51:34 GMT
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.

Mime
View raw message