Details

    • Steps to Reproduce:
      Hide

      Use the attached byteman script

      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 JBoss repeatedly while hitting HA-JNDI until the
      timing is just right to trigger it).

      From a standalone client configured with jndi.properties to hit HA-JNDI, run:
      new InitialContext().lookup ( "foo" );

      Show
      Use the attached byteman script 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 JBoss repeatedly while hitting HA-JNDI until the timing is just right to trigger it). From a standalone client configured with jndi.properties to hit HA-JNDI, run: new InitialContext().lookup ( "foo" );
    • Affects:
      Release Notes
    • Release Notes Text:
      Hide
      In some circumstances, HA-JNDI could start processing requests before it was fully initialized, causing those requests to fail with a NullPointerException. This has now been resolved so that initialization is confirmed before processing begins.
      Show
      In some circumstances, HA-JNDI could start processing requests before it was fully initialized, causing those requests to fail with a NullPointerException. This has now been resolved so that initialization is confirmed before processing begins.
    • 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)

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  dereed Dennis Reed
                  Reporter:
                  dereed Dennis Reed
                  Writer:
                  Russell Dickenson
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: