[jboss-remoting-issues] [JBoss JIRA] Commented: (JBREM-1056) Fix race condition in InvokerRegistry
[
https://jira.jboss.org/jira/browse/JBREM-1056?page=com.atlassian.jira.plu...
]
Ron Sigal commented on JBREM-1056:
----------------------------------
The synchronization in InvokerRegistry has been reorganized so that
1. references to transportClientFactoryClasses and clientLocators are governed by
clientLock, and
2. references totransportServerFactoryClasses, serverLocators, and registeredLocators
are governed by serverLock.
Unit test: org.jboss.test.remoting.registry.InvokerRegistryRaceTestCase.
Changes have been applied to the 2.2 and 2.x branches.
Waiting for results in hudson.
Fix race condition in InvokerRegistry
-------------------------------------
Key: JBREM-1056
URL: https://jira.jboss.org/jira/browse/JBREM-1056
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 2.2.2.SP10, 2.5.0.SP1 (Flounder)
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.2.2.SP11, 2.5.0.SP2 (Flounder)
In org.jboss.remoting.InvokerRegistry.createClientInvoker() there is a reference to
serverLocators which is in a synchronized(clientLock) block but which is not protected by
a synchronized(serverLock) block. Under heavy load, when
org.jboss.remoting.Client.addCallbackListener() is creating a connection to the callback
Connector (which is necessarily colocated in the same JVM), serverLocators has been seen
to return null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira