Potential deadlock here due to order of getWriteLock() and synchronized
(connect_sync) calls being swopped between two methods.
I haven't analysed this fully, nor come up with a fix yet, but am working on
public void closeAllowReopen()
logger.debug (this.toString() + ": closeAllowReopen()");
private final void sendMessage( MessageOutputStream out )
tcs_negotiated = false;
+ ": sendMessage() -- opening transport");
Having looked through the code, there appear to be no other places where this
sequence occurs. As such, simply moving the getWriteLock() up above the
synchronized(connect_sync) in ClientGIOPConnection.java will remove the
possibility of this deadlock without any side effect.
Did you checked the last correction suggested for Bug 708?
I think this already addresses your problem.
Checking CVS head web interface 19/02/2007 the problem is potentially still
here. The order of acquiring the two locks is reversed between
ClientGIOPConnection and GIOPConnection. Whether the situation can still
(ever?) arise may have changed, but it still makes sense to correct this code.
By the way, the download of cvs daily head snapshot for 19/02 does not contain
Created attachment 357 [details]
Patch for Bug 759
This patch fixes a dead lock described in this bug report.
Created attachment 358 [details]
ChangeLog for Patch for Bug 759
Change log for the patch that fixes a dead lock described in this bug report.
I have attached a patch that addresses a dead lock situation stemming from this bug. The dead lock was observed with a post 2.3.0 build that incorporated the fixes for Bug 708.
Patch on this ticket looks like similar code has already been applied to CVS partially as a result of 708.
*** This bug has been marked as a duplicate of bug 708 ***