camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] [Commented] (CAMEL-5870) camel-jms: Avoid DMLC.stop(), as it's buggy under certain conditions
Date Thu, 13 Dec 2012 10:40:17 GMT


Claus Ibsen commented on CAMEL-5870:

The bug is not in Camel but in spring-jms. So people can upgrade to newer spring releases
when they are out.

Though if you change anything in Camel, mind that this will affect

if ppl use the throttling route policy to throttle jms consumers. As the sheer number of suspend/resume
with the destroy may cause degrations / other issues down the road.
> camel-jms: Avoid DMLC.stop(), as it's buggy under certain conditions
> --------------------------------------------------------------------
>                 Key: CAMEL-5870
>                 URL:
>             Project: Camel
>          Issue Type: Task
>    Affects Versions: 2.10.3
>            Reporter: Raul Kripalani
>            Assignee: Raul Kripalani
>             Fix For: 2.9.6, 2.10.4, 2.11.0
> Spring's DefaultMessageListenerContainer leaks MessageConsumers, Sessions and Connections
when maxMessagesPerTask is greater than -1 (i.e. you have defined how many messages you'll
process in each task).
> Here is the bug report:
> This happens if you first call DLMC.stop(), followed by DLMC.destroy(). The stop() method
pauses the consuming tasks, and the destroy() method "forgets" to free the underlying resources.
> We use DLMC.stop() when suspending the JmsConsumer.
> To circumvent this issue, let's destroy the DLMC directly even when suspending the consumer.
It's the safest option for now.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message