XMLWordPrintable

Details

    • Bug
    • Resolution: Obsolete
    • 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

    Description

      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.

      Attachments

        Activity

          People

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

            Dates

              Created:
              Updated:
              Resolved: