XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Obsolete
    • Icon: Major Major
    • None
    • EAP_EWP 5.2.0
    • Messaging
    • None
    • Solaris 10

    • Hide

      The behaviour can be reproduced by intentionally causing any exception within ConsumerAspect.handleClosing().
      One way to cause that could be in the following setup.

      • One JBoss instance works as a jms client,
      • one as a jms server.
      • On the client side one stalls the execution of LeasePinger.run() until on the server side the missing lease-update will be registered (see SuspendLeasePinger.jpg). The jms server then should remove the client (ids, ...) for example by calling Dispatcher.unregisterTarget() (see LeaseNotUpdated.jpg).
      • On the client server instance initiate shutdown.
      • Within the SessionDelegate.closing() there is a remote call of ClosingRequest.serverInvoke() on the jms server instance, which throws an IllegalStateException (see IllegalStateException.jpg).
      • On the client side the exception will be swallowed (MessagingJMSException.jpg).
      Show
      The behaviour can be reproduced by intentionally causing any exception within ConsumerAspect.handleClosing(). One way to cause that could be in the following setup. One JBoss instance works as a jms client, one as a jms server. On the client side one stalls the execution of LeasePinger.run() until on the server side the missing lease-update will be registered (see SuspendLeasePinger.jpg). The jms server then should remove the client (ids, ...) for example by calling Dispatcher.unregisterTarget() (see LeaseNotUpdated.jpg). On the client server instance initiate shutdown. Within the SessionDelegate.closing() there is a remote call of ClosingRequest.serverInvoke() on the jms server instance, which throws an IllegalStateException (see IllegalStateException.jpg). On the client side the exception will be swallowed (MessagingJMSException.jpg).
    • 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.

              gaohoward Howard Gao
              rhn-support-lakagwu Lami Akagwu
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: