-
Bug
-
Resolution: Fixed
-
P2
-
6
-
b07
-
sparc
-
solaris_10
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2197713 | 7 | Sunita Koppar | P4 | Resolved | Fixed | b123 |
JDK-2204968 | 6u25 | Sunita Koppar | P2 | Resolved | Fixed | b01 |
JDK-2204281 | 6u24-rev | Sunita Koppar | P2 | Resolved | Fixed | b22 |
Customer reports issue is in CORBA in Java SE. The issue is beleived to be related to CR 6238477 that was reported and fixed in the Java EE. He's seeing a deadlock in com.sun.corba.se.impl.orb.ORBImpl. Although this issue started in Java 1.5 , he does not need it patched back to 1.5.
Probably the easiest way to pass this on is by letting you know that this
was also fixed in Glass Fish. They did put the bug id in the comment so the customer
believes this should help.
// All access to resolver, localResolver, and urlOperation must be
protected using
// the appropriate locks. Do not hold the ORBImpl lock while accessing
// resolver, or deadlocks may occur.
// Note that we now have separate locks for each resolver type. This is
due
// to bug 6238477, which was caused by a deadlock while resolving a
// corbaname: URL that contained a reference to the same ORB as the
// ORB making the call to string_to_object. This caused a deadlock
between the
// client thread holding the single lock for access to the urlOperation,
// and the server thread handling the client is_a request waiting on the
// same lock to access the localResolver.
I was not able to use the testcase provided in 6238477 in spite of great effort.
However, going by the source code, it is advisable to add another lock since the deadlock is possible, as claimed by the customer.
In addition to this, since we have this fixed in GF already and since the CORBA code in JDK is a copy of the code in GF, it is safe to port the fix for 6238477 into JDK workspace.
Also, the change required here is internal to ORBImpl class and hence the risk of regression or dependency on any other code change is almost nil.
CORBA test setups are generally complicated and considering the current scenario, we need not press for a testcase.
I will try to make the required changes and produce an FVB.
Probably the easiest way to pass this on is by letting you know that this
was also fixed in Glass Fish. They did put the bug id in the comment so the customer
believes this should help.
// All access to resolver, localResolver, and urlOperation must be
protected using
// the appropriate locks. Do not hold the ORBImpl lock while accessing
// resolver, or deadlocks may occur.
// Note that we now have separate locks for each resolver type. This is
due
// to bug 6238477, which was caused by a deadlock while resolving a
// corbaname: URL that contained a reference to the same ORB as the
// ORB making the call to string_to_object. This caused a deadlock
between the
// client thread holding the single lock for access to the urlOperation,
// and the server thread handling the client is_a request waiting on the
// same lock to access the localResolver.
I was not able to use the testcase provided in 6238477 in spite of great effort.
However, going by the source code, it is advisable to add another lock since the deadlock is possible, as claimed by the customer.
In addition to this, since we have this fixed in GF already and since the CORBA code in JDK is a copy of the code in GF, it is safe to port the fix for 6238477 into JDK workspace.
Also, the change required here is internal to ORBImpl class and hence the risk of regression or dependency on any other code change is almost nil.
CORBA test setups are generally complicated and considering the current scenario, we need not press for a testcase.
I will try to make the required changes and produce an FVB.
- backported by
-
JDK-2204281 CORBA deadlock in Java SE beleived to be related to CR 6238477
-
- Resolved
-
-
JDK-2204968 CORBA deadlock in Java SE beleived to be related to CR 6238477
-
- Resolved
-
-
JDK-2197713 CORBA deadlock in Java SE beleived to be related to CR 6238477
-
- Resolved
-