[jboss-remoting-issues] [JBoss JIRA] Commented: (JBREM-1112) Potential race between ConnectionValidator and ConnectionListener upon connection failure
Ron Sigal (JIRA)
jira-events at lists.jboss.org
Fri Apr 3 01:52:22 EDT 2009
[ https://jira.jboss.org/jira/browse/JBREM-1112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12460414#action_12460414 ]
Ron Sigal commented on JBREM-1112:
----------------------------------
A new parameter, ConnectionValidator.FAILURE_DISCONNECT_TIMEOUT (actual value "failureDisconnectTimeout") has been introduced. It may be set in the InvokerLocator (if org.jboss.remoting.Client.USE_ALL_PARAMS (actual value "useAllParams") is set to "true), the Client's configuration map, or the metadata map passed to Client.addConnectionListener().
If "failureDisconnectTimeout" is set to an integer value other than -1, then ConnectionValidator uses that value when it calls ClientInvoker.terminateLease(). Otherwise, it uses the value returned by Client.getDisconnectTimeout().
Unit test: org.jboss.test.remoting.connection.ConnectionValidatorDisconnectTimeoutTestCase.
The changes have been applied to the 2.2 branch.
> Potential race between ConnectionValidator and ConnectionListener upon connection failure
> -----------------------------------------------------------------------------------------
>
> Key: JBREM-1112
> URL: https://jira.jboss.org/jira/browse/JBREM-1112
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11
> Reporter: Ron Sigal
> Assignee: Ron Sigal
> Fix For: 2.5.0.SP3 (Flounder), 2.2.2.SP12
>
>
> When org.jboss.remoting.ConnectionValidator.WaitOnConnectionCheckTimerTask detects a connection failure, it informs all registered ConnectionListeners and then, if the parameter "stopLeaseOnFailure" is set to "true", it calls
> invoker.terminateLease(null, client.getDisconnectTimeout());
> The idea is that a ConnectionListener might want to set the Client's disconnectTimeout value to limit the time spent on network i/o while shutting down a faulty connection. In particular, if disconectTimeout is set to 0, then Remoting will skip any i/o while shutting down a connection.
> The problem is that, in ConnectionValidator.notifyListeners(), each registered ConnectionListener is called in a separate thread, to avoid getting hung up in a particular ConnectionListener. As a result, it is possible for ConnectionValidator to call Client.getDisconnectTImeout() before any ConnectionListener gets a chance to call Client.setDisconnectTimeout().
> In particular, this race has been discovered in the context of a JBossMessaging application.
--
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
More information about the jboss-remoting-issues
mailing list