[9] RFR of JDK-8085192: java/rmi/activation/Activatable tests fail intermittently due to "Port already in use"

Roger Riggs Roger.Riggs at Oracle.com
Wed Oct 5 20:08:14 UTC 2016


Hi Chris,

Some comments,

BTW, there is a newer version of Webrev that provides convenient next 
and prev links...


* sun/rmi/server/Activation.java: 1973
  - I'd stick to the normal set of values for a boolean system property: 
use java.lang.Boolean.getProperty("sun.rmi....").

* With so many dependencies, how about adding the modules = to an 
appropriate TEST.properties file.

* With the extra security permissions and breaking into package private 
utilities
    this test is going to be more fragile and harder to work with.

* 
test/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.java
  - line 184, leftover println...  (or incorrectly indented).
  - line 226 ditto?

* test/java/rmi/activation/Activatable/extLoadedImpl/ExtLoadedImplTest.java
+ 
test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java
+ 
test/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.java
+ 
test/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java
+ 
test/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.java
+ 
test/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.java
+ 
test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java
+ test/java/rmi/activation/CommandEnvironment/SetChildEnv.java
+ 
test/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.java
+ 
test/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.java
+
  - Do these tests also need @module java.base/sun.nio.ch

* I wonder of the security.policy and rmid.security.policy files can be 
(mostly) shared.
   (but that's not really this issue)

* test/java/rmi/testlibrary/RMID.java
  - 139: typo "do no" -> "do not"

I'm vaguely not very comfortable with scraping the port number off stdout
and the inherited channel pieces seem like a lot of moving parts.

Roger

p.s.  Anyother idea
I assume not all platforms can allow separate processes to open server 
sockets to the same port.
If so, we would just have the client allocate a port (0), mark it 
non-exclusive and keep it open
while passing the port number to RMID. Only after RMID is started close 
the allocating socket.






On 10/3/2016 11:42 AM, Chris Hegarty wrote:
> Here is an updated version of this ( ready for review ):
>
>   http://cr.openjdk.java.net/~chegar/8085192_webrev.02/
>
> Changes from previous:
>
> 1) Updated Activation/rmid to NOT redirect stderr, if an
>    implementation specific system property is used ( we can
>    discuss the name )
>
> 2) For now, I added createRMIDOnEphemeralPort, rather than
>    change the current implementation, as it is being used in
>    other places. We can revert this once other usages are
>    updated and verified.
>
> -Chris.
>
> On 29/09/16 20:09, Chris Hegarty wrote:
>> On 29 Sep 2016, at 16:25, Chris Hegarty <chris.hegarty at oracle.com> 
>> wrote:
>>>
>>> I have asked Hamlin to hold off on this for a day or so.  I have an
>>> alternative proposal that eliminates the free port anti-pattern.
>>
>> It is possible to use the inheritedChannel mechanism to have the rmid
>> process create the server channel on an ephemeral port and report it
>> back to the test, i.e. remove the free port pattern.
>>
>> http://cr.openjdk.java.net/~chegar/8085192_webrev/
>>
>> 1) The port number is reported from rmid to the test over stdout.
>>
>> 2) All tests pass except CheckAnnotations.java, which looks for stderr
>>     ( see 3 below ). I think the stderr check can be removed, and the
>>     just check stdout.
>>
>> 3)  rmid, when using inheritChannel, redirects stderr to a tmp file, so
>>      it is not possible to get the processes stderr over the processes
>>      stderr pipe. I did’t find that this was an issue when testing ( 
>> other
>>      than having to clear out /tmp )
>>
>> 4) This could be expanded to other tests, outside of activation, to
>>      remove more usages of free port.
>>
>> This is not yet complete, I just want to share the idea to see if it 
>> is a
>> runner, or not.
>>
>> -Chris.
>>



More information about the core-libs-dev mailing list