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.
