You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Claus Ibsen (JIRA)" <ji...@apache.org> on 2016/04/22 08:33:12 UTC
[jira] [Commented] (CAMEL-9900) camel-jms - provide option for
MessageListenerContainer for reply managers to stop quicker when
CamelContext is stopping
[ https://issues.apache.org/jira/browse/CAMEL-9900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15253445#comment-15253445 ]
Claus Ibsen commented on CAMEL-9900:
------------------------------------
Remember to add the option to wiki
http://camel.apache.org/jms
> camel-jms - provide option for MessageListenerContainer for reply managers to stop quicker when CamelContext is stopping
> ------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-9900
> URL: https://issues.apache.org/jira/browse/CAMEL-9900
> Project: Camel
> Issue Type: Improvement
> Reporter: Jonathan Anstey
> Assignee: Jonathan Anstey
> Fix For: 2.17.1, 2.18.0
>
>
> CAMEL-7667 included a fix for the DMLC used in JMS consumers to stop quickly if the CameContext is already shutting down. This helps avoid spring-jms getting into a bad state with a null sharedConnection which has a telling stack like:
> {code}
> 2014-08-07 10:33:42,975 [sonnel.records]] ERROR ultJmsMessageListenerContainer - Could not refresh JMS Connection for destination 'personnel.records' - retrying in 5000 ms. Cause: null
> java.lang.NullPointerException
> at org.springframework.jms.listener.AbstractJmsListeningContainer.refreshSharedConnection(AbstractJmsListeningContainer.java:392)
> at org.springframework.jms.listener.DefaultMessageListenerContainer.refreshConnectionUntilSuccessful(DefaultMessageListenerContainer.java:885)
> at org.springframework.jms.listener.DefaultMessageListenerContainer.recoverAfterListenerSetupFailure(DefaultMessageListenerContainer.java:861)
> at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1012)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}
> This can also occur in the DMLC used for request-reply messaging. We should provide an option for this to be enabled because usually this is not an issue and you don't mind waiting for a while for replies to come in.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)