-
Bug
-
Resolution: Fixed
-
P3
-
6
-
b55
-
generic
-
generic
-
Verified
The problem is not related to the type of monitor : it fails with either gauge or string or counter.
The scenario is the following:
- we start more monitors than the amount of threads in the pool
- we stop all monitors
- we start less monitors than the amount of threads in the pool
- we stop all monitors
and then we loop over.
The issue occurs during the second loop, first call to call : the user code stays stuck during more than one hour.
Note that we reproduce it on slow and single processor Sparc systems such as Ultra 10 and not on faster or multi processors systems. For that reason, it has been seen with Solaris only.
The test is live since b39.
Attached full thread dump when stuck.
###@###.### 2005-06-13 14:27:11 GMT
The scenario is the following:
- we start more monitors than the amount of threads in the pool
- we stop all monitors
- we start less monitors than the amount of threads in the pool
- we stop all monitors
and then we loop over.
The issue occurs during the second loop, first call to call : the user code stays stuck during more than one hour.
Note that we reproduce it on slow and single processor Sparc systems such as Ultra 10 and not on faster or multi processors systems. For that reason, it has been seen with Solaris only.
The test is live since b39.
Attached full thread dump when stuck.
###@###.### 2005-06-13 14:27:11 GMT
- relates to
-
JDK-6303187 Monitor synchronization could lead to deadlock
-
- Resolved
-