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.plum...@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
>
>
