RFR for JDK-8035388: TEST_BUG: java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.java fails

Stuart Marks stuart.marks at oracle.com
Tue Feb 25 21:47:15 UTC 2014

On 2/25/14 12:34 AM, Tristan Yan wrote:
> Could you please help to review code fix for JDK-8035388.
> http://cr.openjdk.java.net/~tyan/JDK-8035388/webrev.00/
> Description:
> method inactiveObject in ActivationGroupImpl.java, release lock happen before
> checkInactiveGroup. This makes groupInactive reset even before next
> inactiveObject started.

Hi Tristan,

Unfortunately the changes to 
src/share/classes/sun/rmi/server/ActivationGroupImpl.java of the form,

          } finally {
-            releaseLock(id);
+            releaseLock(id);

are incorrect. These changes expand the scope of the acquireLock/releaseLock 
pair to include the call to checkInactiveGroup. The acquireLock/releaseLock 
methods in this class maintain a list of locked activation IDs in the 
"lockedIDs" list. The presence of an ID in this list indicates that it's been 

The problem with having checkInactiveGroup() within the scope of the 
acquireLock/releaseLock is that checkInactiveGroup has this code:

             if (active.size() == 0 && lockedIDs.size() == 0 &&
                 groupInactive == false)
                 groupInactive = true;
                 groupMarkedInactive = true;

Thus, if checkInactiveGroup() is called before releaseLock(), the lockedIDs list 
will always have at least one member, and the condition will always be false. 
Therefore, this activation group will **never** be made inactive, even if all 
activated objects within the group become inactive. That's a bug.

The test passes because it successfully reactivates an object within the same 
activation group. However, the intent of the test is to inactivate the group, 
then reactivate the object, forcing rmid to spawn a new activation group. The 
changes in this patch don't fulfil this intent.


More information about the core-libs-dev mailing list