Uploaded image for project: 'JBoss Enterprise Application Platform 4 and 5'
  1. JBoss Enterprise Application Platform 4 and 5
  2. JBPAPP-8152

HA-JNDI still processes requests before fully initialized

    Details

    • Steps to Reproduce:
      Hide

      Use the attached byteman script on one node of a 2 or more node cluster.

      JAVA_OPTS=-javaagent:$BYTEMAN_HOME/lib/byteman.jar=script:/path/to/pauseHAJNDIinit.btm

      (This script just pauses at the right spot to make it easier to trigger the bug.
      Without the script, just restart one member of the cluster repeatedly while hitting HA-JNDI until the
      timing is just right to trigger it).

      Start the other member(s) of the cluster except for the one with the byteman script.

      From a standalone client configured with jndi.properties to hit HA-JNDI, run:

      InitialContext context = new InitialContext()
      while ( true )
      context.lookup ( ... );

      Start the member with the byteman script.

      Show
      Use the attached byteman script on one node of a 2 or more node cluster. JAVA_OPTS=-javaagent:$BYTEMAN_HOME/lib/byteman.jar=script:/path/to/pauseHAJNDIinit.btm (This script just pauses at the right spot to make it easier to trigger the bug. Without the script, just restart one member of the cluster repeatedly while hitting HA-JNDI until the timing is just right to trigger it). Start the other member(s) of the cluster except for the one with the byteman script. From a standalone client configured with jndi.properties to hit HA-JNDI, run: InitialContext context = new InitialContext() while ( true ) context.lookup ( ... ); Start the member with the byteman script.
    • Affects:
      Release Notes
    • Release Notes Text:
      Hide
      An issue that resulted in clients receiving errors has been resolved in this release. It was determined that HAJNDI was processing results before it was fully initialized, and the errors were coming from components that were not in the correct state. The issue has been corrected and HAJNDI now throws <literal>javax.naming.ServiceUnavailableException</literal>, which can be handled to retry the request automatically, if a request comes in during start up.
      Show
      An issue that resulted in clients receiving errors has been resolved in this release. It was determined that HAJNDI was processing results before it was fully initialized, and the errors were coming from components that were not in the correct state. The issue has been corrected and HAJNDI now throws <literal>javax.naming.ServiceUnavailableException</literal>, which can be handled to retry the request automatically, if a request comes in during start up.
    • Release Notes Docs Status:
      Documented as Resolved Issue
    • Docs QE Status:
      NEW

      Description

      HAJNDI starts processing requests before it has fully initialized itself.
      This can cause those requests to fail with:

      java.lang.NullPointerException
      at org.jboss.ha.jndi.impl.jbc.JBossCacheDistributedTreeManager.lookup(JBossCacheDistributedTreeManager.java:313)
      at org.jboss.ha.jndi.HAJNDI.lookup(HAJNDI.java:197)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.ha.framework.server.HARMIServerImpl.invoke(HARMIServerImpl.java:209)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
      at sun.rmi.transport.Transport$1.run(Transport.java:159)
      at java.security.AccessController.doPrivileged(Native Method)
      at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
      at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
      at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
      at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
      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:662)

      This is related to https://issues.jboss.org/browse/JBPAPP-6408.
      That patch fixes this issue for "new InitialContext().lookup(...)" while JBoss is starting.

      This issue can still occur with:

      InitialContext context = new InitialContext()
      while ( true )
      context.lookup ( ... );

      while a member of the cluster is restarted after the "new InitialContext()" succeeds.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  dereed Dennis Reed
                  Reporter:
                  dereed Dennis Reed
                  Writer:
                  Scott Thomas
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  3 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: