jmx-dev 8221303: sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java fails due to java.rmi.server.ExportException: Port already in use

Chris Plummer chris.plummer at oracle.com
Wed Jul 17 20:47:17 UTC 2019


Hi Daniil,

I think you can remove "Ok" from the following message:

  237 System.out.println("DEBUG: OK. Spawned java process terminated 
with expected exit code of "
  238                         + STOP_PROCESS_EXIT_VAL);

It's somewhat misleading since the test can still fail. I think the 
following is also misleading:

  249             if (testFailed) {
  250                 output.reportDiagnosticSummary();
  251                 if (output.getStderr().contains("Port already in 
use")) {
  252                     // Need to retry
  253                     return true;
  254                 }
  255             }

The test can still pass after this happens, right? And I think there are 
other "Test FAILURE" error message that can appear just before this. 
Perhaps the code above should add a println that indicates that there 
will be a retry attempt since the failure was due to the port being in use.

Otherwise looks good.

thanks,

Chris

On 7/17/19 1:30 PM, Alex Menkov wrote:
> Hi Daniil,
>
> The fix looks good in general.
> Couple cosmetic notes (no new webrev required):
>
>  162                 needRetry = runTest();
>  163             }
>  164             while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS));
> Please move "while" to the prev line:
>  163             } while (needRetry && (attempts++ < MAX_RETRY_ATTEMTS));
>
>
>  242                     System.out.println("Test FAILURE on" + name + 
> " reason: The expected line \"" + READY_MSG
>  243                             + "\" is not present in the process 
> output");
> Please add space: "Test FAILURE on " + name
>
> --alex
>
> On 07/17/2019 12:46, Daniil Titov wrote:
>> Hi Chris,
>>
>>>     It's a little unclear to me why you moved from ProcessThread to
>>>    TestProcessThread + Process. An explanation of that would make it 
>>> easier
>>>    to understand many of the changes.
>>
>> There are two reasons for that:
>> 1)  For every network interface the test starts a separate thread 
>> that runs the test for this interface. We want that if the test fails
>>      due to the bind error the thread not to exit but try to repeat 
>> the test several times. jdk.test.lib.thread.ProcessThread doesn't 
>> allow this.
>> 2) To filter out the cases when the test fails due to the bind error 
>> we need to parse the process output. jdk.test.lib.thread.ProcessThread
>>    registers its own pumps for stdin and sdtout  (by calling 
>> ProcessTools.startProcess()) that consume all output of the process 
>> and prevent
>>    the output analyzer from collecting this output.
>>   Thanks!
>> --Daniil
>>
>> On 7/17/19, 12:11 PM, "Chris Plummer" <chris.plummer at oracle.com> wrote:
>>
>>      Hi Daniil,
>>           It's a little unclear to me why you moved from 
>> ProcessThread to
>>      TestProcessThread + Process. An explanation of that would make 
>> it easier
>>      to understand many of the changes.
>>           thanks,
>>           Chris
>>           On 7/11/19 10:16 AM, Daniil Titov wrote:
>>      > Please review the change that fixes an intermittent failure of 
>> sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java
>>      > test due to ports collision. The tests finds all network 
>> interfaces and for every interface starts a separate process that tests
>>      > the connection to JMX agent server for a specific 
>> ports/interface combination.
>>      >
>>      > The test was changed to retry in case of the failure. If the 
>> subprocess fails to bind and the number
>>      > of retry attempts doesn't exceed the limit a new pair of 
>> random ports is selected and the test is run again.
>>      >
>>      > Webrev: http://cr.openjdk.java.net/~dtitov/8221303/webrev.01/
>>      > Bug: https://bugs.openjdk.java.net/browse/JDK-8221303
>>      >
>>      > Thanks!
>>      > --Daniil
>>      >
>>      >
>>
>>



More information about the serviceability-dev mailing list