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