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);
checkInactiveGroup();
+ 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
locked.
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.
s'marks
