RFR: 8263729: [test] Extend time to wait before destroying child in ProcssBuilder Basic test

[Roger Riggs]

On Wed, 17 Mar 2021 20:03:16 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Its a Java Child for consistency across tests and across OS's.  
>> The JavaChild executes a number of specialized commands to consume or provide data to the parent.
>> Piecing that together on different OS's would add more variables to the tests.
>> In this particular case, assuming it's well understood could probably be handled by some native program
>> as long its available on all platforms consistently.
>
>> Its a Java Child for consistency across tests and across OS's.
>> The JavaChild executes a number of specialized commands to consume or provide data to the parent.
>> Piecing that together on different OS's would add more variables to the tests.
>> In this particular case, assuming it's well understood could probably be handled by some native program
>> as long its available on all platforms consistently.
> 
> Thanks Roger for explaining. Sorry for the questions. We are bugged regularly by similar intermittent errors and I am curious and interested in getting tests stable.
> 
> I'm still thinking reading both stdout and stderr simultaneously would be more defensive in case the child dies of unnatural circumstances, or prints out unexpected output. The VM does this sometimes (eg unconditonal logging, or crashing), and we have seen blockages like these when childs waited on unflushed write buffers. Since you have all parts already there - a thread to drain the childs output - why not just spawn two of those instead of one and make sure both are closed as expected when the child is gone. That way you also cut down on execution time.

The test expects there to be zero output from the child (and it doesn't matter what state the child is in).
Can the logging from the VM be disabled or re-directed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3049