Summary: | Deadlock in GIOPConnection | ||
---|---|---|---|
Product: | JacORB | Reporter: | Richard Ridgway <Richard_Ridgway> |
Component: | ORB | Assignee: | Gerald Brose <gerald.brose> |
Status: | RESOLVED DUPLICATE | ||
Severity: | major | CC: | Richard_Ridgway, rnc |
Priority: | P4 | ||
Version: | 2.3.0 beta 2 | ||
Hardware: | All | ||
OS: | All | ||
Attachments: |
Patch for Bug 759
ChangeLog for Patch for Bug 759 |
Description
Richard Ridgway
2007-02-09 15:39:03 CET
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. Regards, Richard 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 source code. 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. |