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 2012/09/22 10:26:07 UTC

[jira] [Commented] (CAMEL-5636) Camel JMS consumer freezes after an unhandled exception

    [ https://issues.apache.org/jira/browse/CAMEL-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13461066#comment-13461066 ] 

Claus Ibsen commented on CAMEL-5636:
------------------------------------

Its not the jms consumer that is the problem. Its the async routing engine that waits for a reply that is not coming back. Are you using any custom components. 

And as always upgrade your Camel version to see if its fixed, eg Camel 2.8.0 is an old release.
                
> Camel JMS consumer freezes after an unhandled exception
> -------------------------------------------------------
>
>                 Key: CAMEL-5636
>                 URL: https://issues.apache.org/jira/browse/CAMEL-5636
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-jms
>            Reporter: Raul Kripalani
>            Assignee: Raul Kripalani
>             Fix For: 2.8.0
>
>
> Just experienced an issue with a camel-jms consumer freezing after an unhandled exception. 
> This is the relevant thread from the thread dump:
> {code}
> "Camel (context) thread #10 - JmsConsumer[queue]" daemon prio=5 tid=103666000 nid=0x113c25000 waiting on condition [113c24000]
>    java.lang.Thread.State: WAITING (parking)
>         at sun.misc.Unsafe.park(Native Method)
>         - parking to wait for  <7fd4a8de0> (a java.util.concurrent.CountDownLatch$Sync)
>         at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
>         at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
>         at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
>         at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:120)
>         at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:85)
>         at org.apache.camel.component.jms.EndpointMessageListener.onMessage(EndpointMessageListener.java:91)
>         at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:560)
>         at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:498)
>         at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:467)
>         at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:325)
>         at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:263)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1058)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1050)
>         at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:947)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:680)
> {code}
> Consumer doesn't pick up any new messages thereon, and stays in this state forever. When running inside SMX, the container has to be killed with a SIGKILL. A SIGTERM has no effect.

--
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: http://www.atlassian.com/software/jira