RFR of JDK-8134599: TEST_BUG: java/rmi/transport/closeServerSocket/CloseServerSocket.java fails intermittently with Address already in use

Seán Coffey sean.coffey at oracle.com
Tue Oct 15 09:19:45 UTC 2019


Quite a while since I touched this one! The nature of the test is a bit 
flaky given
that we're assuming no other process will use the chosen port. I'm not sure
if a concrete solution is possible. One other option is to have this 
test run
in non-concurrent mode by editing test/jdk/TEST.ROOT --> 
exclusiveAccess.dirs=

The while loop approach may help but won't protect against cases where a
long running process has attached to the port number we're interested in.

regards,
Sean.

On 15/10/2019 03:20, Weijun Wang wrote:
> +SeanC
>
> The wait might unnecessarily increase the test time. Maybe you can do something like this:
>
>     int timeout = 10;
>     while (timeout > 0) {
>        sleep(one second);
>        verifyPortFree && return;
>        timeout--;
>     }
>     throw new Exception(still not freed);
>
> And Sean, back in JDK-8016728 you said "Let's extend it to 1000ms and see how test behaves". So what do you think?
>
> Thanks,
> Max
>
>> On Oct 15, 2019, at 10:03 AM, Hamlin Li <huaming.li at oracle.com> wrote:
>>
>> Hi,
>>
>> The test is failing more frequently, could some help to review it?
>>
>> Thank you
>>
>> -Hamlin
>>
>> On 2019/9/4 11:11 AM, Hamlin Li wrote:
>>> some background & comment: in most of failures, the "test.timeout.factor" is 10.0 or 8.0, so in the test code this factor should be considered in rmi operations such unexporting an object.
>>>
>>> Thank you
>>>
>>> -Hamlin
>>>
>>> On 2019/9/4 11:01 AM, Hamlin Li wrote:
>>>> Hi,
>>>>
>>>> Would you please review the following patch?
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8134599
>>>>
>>>> webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/
>>>>
>>>>
>>>> Thank you
>>>>
>>>> -Hamlin
>>>>


More information about the core-libs-dev mailing list