JDK-7161503 : java/rmi/activation/CommandEnvironment/SetChildEnv.java test fails
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 8-pool
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2012-04-13
  • Updated: 2012-07-23
  • Resolved: 2012-07-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Resolved
Related Reports
Duplicate :  
JDK-7142596 - TEST_BUG: many RMI tests fail because of port conflicts
Relates :  
JDK-7168267 - TEST_BUG: Cleanup of rmi regression tests (activation and others)
Description
java/rmi/activation/CommandEnvironment/SetChildEnv.java fails due to the commit of the fix for Bug#7142596.
Comments
EVALUATION Before the concurrency fix from using different ports (7142596), SetChildEnv was using the default port in the 4 sequential calls to runwith() method. That could work only because the ActivationSystem retrieved from *first* call to ActivationGroup.getSystem(), a static variable of class ActivationGroup that cannot be changed once set, contained consistent (host, name, port) information with subsequent calls to runwith, even if rmid instances where different in the subsequent calls. Given the set of calls inside it, SetChildEnv is wrongly written: either it should create only once an activation daemon and only use the associated activation system, or it should be splitted in four different subprograms, each of which creating an activationSystem only once inside the running vm. Thus, trying to use different ports inside SetChildEnv *cannot* work because the Activation framewwork API enforces the use of *only one* ActivationSystem instance inside one VM (the one that run SetChildEnv.main()). When an ActivationSystem inside a vm is set, you cannot change/reset it anymore. You are done and it is fixed for the lifetime of this vm. So the failure in 7161503 is in fact normal and expected, due to the way it is designed and writen. SetChildEnv can use one port and one ActivationSystem only, not several.
04-07-2012
SUGGESTED FIX The aim of fixing this bug is not to fix SetChildEnv feature, but make the use of different ports (7142596 concurrency fix) valid in all activation tests. So the fix should consist in reverting to a situation that is equivalent to the one before 7142596 fix, not to rewrite SetChildEnv regression test. That is : - the port number used in successive calls to runwith is chosen at the beginning of main() call, and is reused for all successive runwith() calls. - this port number is retrieved from TestLibrary.getUnusedRandomPort(). Doing this, SetChildEnv will work again by the same fortunate coincidence as before (see evaluation). However, considering the longer term, and in an effort of cleaning up the RMI regression tests (see 7168267), the program should be fixed either being splitted or using only one activationSystem and rmid.
04-07-2012