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

[Anders Persson (JIRA)]

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

Anders Persson reopened JGRP-578:
---------------------------------

             
Well, I would definitely not make JChannel depend on the leaving flag in GMS. In my view JChannel should be kept complety protocol neutral.

The solution I see is to introduce an abort method in Protocol. Calling this method would have the effect that the protocol (subclass to Protocol) ceases its current blocking activites, much like you have an "abort flag" that you every now and then check when you are running a thread. The contract would then be that a protocol is obliged to implement abort in case it has any blocking activities. In the case of GMS it would mean that abort() would do the same as stop(), that is, set the leaving flag to true.

The pseudo code in JChannel would be something like

public close()
protocolStack.abort()
synchronized(this)

In other words the synchronized block is only started once the abort has been called. You would keep the synchronized statement on the connect method as is. The synchronization ensures that connect() will finish its business before close() proceeds. I see this as a simple and clean approach to solve this issue. It is a generic way to implement the workaround already described.

> 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