[jboss-jira] [JBoss JIRA] Created: (JBREM-846) Fix race in JNIDDetector

[Ron Sigal (JIRA)]

Fix race in JNIDDetector
------------------------

                 Key: JBREM-846
                 URL: http://jira.jboss.com/jira/browse/JBREM-846
             Project: JBoss Remoting
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 2.2.2.SP2, 2.2.2.GA_CP01, 2.4.0.Beta1 (Pinto)
            Reporter: Ron Sigal
         Assigned To: Ron Sigal
             Fix For: 2.4.0.Beta1 (Pinto)


When the org.jboss.remoting.detection.jndi.JNDIDetector heartbeat thread does a clean detect and discovers that a server is unreachable, it calls checkInvokerServer(), which, among other things, tells its org.jboss.remoting.network.NetworkRegistry to inform listeners of the loss of a server.  It then calls org.jboss.remoting.detection.AbstractDetector.detect(), passing the org.jboss.remoting.detection.Detection representing the server that is no longer available.  However, detect() treats the Detection as a *new* server, and it tells its org.jboss.remoting.network.NetworkRegistry to inform listeners of a new server.

This problem was turned up by the occasional failure of org.jboss.test.remoting.detection.jndi.RestartTestCase.  The test fails inconsistently because NetworkRegistry sends its notifications in separate threads, and RestartTestCase is expecting to hear that (1) the old server has died, and (2) a new server has replaced it.  If the notifications are received in order, than the test passes, and if they are received out of order it fails.

The solution is simply to not call AbstractInvoker.detect() when a server has died.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira