RFR: JDK-8160240 - javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java failed with error "Address already in use: bind"

[Mark Sheppard]

Hi Roger,
   thanks for the feedback and suggestion.

so is the suggestion one of parsing the command line of the test to 
extract the -port argument and then fabricate the
NS port with an increment, and then pass this into the startComponents 
method and thus, eliminate the
security manager check?

I'm not too keen on using ephemeral ports for the tests.
the port # chosen are not in the ephemeral range on any test platform 
(or at least shouldn't be, afaik)
they are a variation on the default ports of 1050 1049 .... 4050 4049, 
5050 5049.
The issue stems from the tests executing faster than the kernel releases 
TCP resources when
terminating connections have closed and it is intermittent

as I understand it, TestLibrary.Utils.freeport() may have some issues 
also, in that it grabs a port by creating a Socket and then
releases, and then indicates it is available for use, as a free port, 
based on the assumption that this port wont be a candidate for
immediate selection in the ephemeral range ... this may not always be 
the case.

regards
Mark

On 01/07/2016 17:01, Roger Riggs wrote:
> Hi Mark,
>
> Instead of spreading around the condition and the port numbers, can 
> you pass the pair of port numbers (as int's)
> to startOrbD and startRmiIiopServer?  That would allow the logic for 
> changing the port numbers to be
> put into startTestComponents.
>
> And you could take advantage of the TestLibrary.Utils.freeport() to 
> pick a free port.
>
> Roger
>
>
> On 7/1/2016 11:45 AM, Seán Coffey wrote:
>> Mark,
>>
>> fixed port numbers are always going to be problematic in tests. Is 
>> there any way the port numbers can be assigned after the test starts 
>> up ? Maybe the com.sun.jndi.cosnaming.CNCtxFactory class could be 
>> modified/accessed via reflection so that the initUsingIiopUrl can be 
>> re-called once you're sure of a free port on test client.
>>
>> That failing, maybe you can use a try/finally block in main method to 
>> ensure that stopTestComponents() is always called. Looks like there's 
>> potential for the test to exit early without cleaning up if 
>> startRmiIiopServer() runs into an exception.
>>
>> Regards,
>> Sean.
>>
>> On 01/07/16 00:38, Mark Sheppard wrote:
>>> Hi,
>>>   please oblige and review the following change
>>> http://cr.openjdk.java.net/~msheppar/8160240/webrev/
>>>
>>> to address the issue raised in
>>> https://bugs.openjdk.java.net/browse/JDK-8160240
>>>
>>> it has been observed that, during continuous integration regression 
>>> tests on some platforms,
>>> there is an intermittent bind failure, when starting the orbd for 
>>> the test. Thus, as the test is composed of
>>> two run commands, one without security manager and one with security 
>>> manager, it is
>>> assumed that, the second run starts before the sockets in use in the 
>>> first run have been fully released.
>>> Therefore, to overcome the bind already in use port conflict, the 
>>> test's second run with security manager
>>> has been modified to use different ports, for cos nameservice and 
>>> activator, to those of the first run.
>>>
>>> regards
>>> Mark
>>
>