-
Bug
-
Resolution: Obsolete
-
Major
-
None
-
EAP_EWP 5.2.0
-
None
-
Solaris 10
-
-
NEW
We have encountered a possible bug in JBoss 5.2 that prevents a JBoss instance from shutting down.
We have to resort to killing the process to shut down the instance
**snip**
"JBoss Shutdown Hook" daemon prio=3 tid=0x0000000127fa0800 nid=0x4929 in Object.wait() [0xfffffffe1ce19000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0xfffffffea9184230> (a java.util.concurrent.ConcurrentHashMap)
at java.lang.Object.wait(Object.java:503)
at org.jboss.jms.client.container.ThreadValveCounter.waitForCompletion(ThreadValveCounter.java:89) - locked <0xfffffffea9184230> (a java.util.concurrent.ConcurrentHashMap)
at org.jboss.jms.client.container.ClosedInterceptor.checkCloseAlreadyDone(ClosedInterceptor.java:245)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:143)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientConsumerDelegate.close(ClientConsumerDelegate.java)
at org.jboss.jms.client.container.ClosedInterceptor.maintainRelatives(ClosedInterceptor.java:294)
at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:167)
at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:86)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.jms.client.delegate.ClientSessionDelegate.closing(ClientSessionDelegate.java)
at org.jboss.jms.client.JBossConnectionConsumer.doClose(JBossConnectionConsumer.java:337) - locked <0xfffffffeaaba2690> (a org.jboss.jms.client.JBossConnectionConsumer)
at org.jboss.jms.client.JBossConnectionConsumer.close(JBossConnectionConsumer.java:163)
at org.jboss.resource.adapter.jms.inflow.JmsServerSessionPool.teardownConsumer(JmsServerSessionPool.java:307)
at org.jboss.resource.adapter.jms.inflow.JmsServerSessionPool.stop(JmsServerSessionPool.java:97)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardownSessionPool(JmsActivation.java:771)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.teardown(JmsActivation.java:377)
at org.jboss.resource.adapter.jms.inflow.JmsActivation.stop(JmsActivation.java:257)
at org.jboss.resource.adapter.jms.JmsResourceAdapter.endpointDeactivation(JmsResourceAdapter.java:79)
at org.jboss.resource.deployers.RARDeployment.endpointDeactivation(RARDeployment.java:346)
at org.jboss.resource.deployers.RARDeployment.internalInvoke(RARDeployment.java:293)
at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:156)
at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
**snip**
During shutdown of a server instance, threads which are waiting for a jms message with ClientConsumer.getMessage() are not woken up during SessionDelegate.closing() because of an exception that happens during ClosingRequest.serverInvoke(), since exceptions are not dealt with in ClosedIntreceptor.invoke(). The Shutdown Hook then waits indefinitely for that all receiver threads have left the client consumer.