[jboss-jira] [JBoss JIRA] Resolved: (JGRP-578) It is possible to create a deadlock when trying to close a channel which is not yet connected

Bela Ban (JIRA) jira-events at lists.jboss.org
Tue Aug 21 07:13:31 EDT 2007


     [ http://jira.jboss.com/jira/browse/JGRP-578?page=all ]

Bela Ban resolved JGRP-578.
---------------------------

    Resolution: Rejected

Connect() and disconnect() or close() are not supposed to be called from different threads, so the above issue is a bit artificial.
I don't want to move the lock down (e.g. around leaving) as this increases the finite state space and therefore complicates the code.
I intend to remove the disable_initial_coord in 3.0 anyway, so this issue is moot.
Since there is a workaround for cancellation of connect(), your code should continue running fine.

> It is possible to create a deadlock when trying to close a channel which is not yet connected
> ---------------------------------------------------------------------------------------------
>
>                 Key: JGRP-578
>                 URL: http://jira.jboss.com/jira/browse/JGRP-578
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.5
>         Environment: Windows XP; java 1_5_0_12
>            Reporter: Anders Persson
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>
> The problem lies in the fact that both connect() and close() in JChannel are synchronized on the same object, the channel. Now lets assume that you have called connect() on the channel. This will eventually take us to the join(Address mbr) in ClientGmsImpl. Now if the channel cannot connect for some reason the code will be stuck here in the while(!leaving) clause until such time that the connection can be established. Now if the user in the meantime decides to quit you will have to call close() on the channel. Unfortuanately nothing will happen since the initial connect is still holding the lock to the channel. Deadlock.
> Now to how to create the hanging join. That is pretty simple by just setting the disable_initial_coord flag and making sure that the entity set to be the coordinator is not available (i.e. not started). I know that you intend to deprecate this flag eventually but first of all we totally depend on this flag for a correct behaviour in our environment and secondly I assume that you will introduce something similar in the upcoming  3.0 version.

-- 
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

        



More information about the jboss-jira mailing list