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