Jaroslav Bachorik wrote:
On 4.2.2014 09:54, shanliang wrote:
Jaroslav,
Your fix should work in most case, but is it better and more reliable to
wait a VM event as suggested in the bug? even your timeout is adapted to
the test time factory, but the solution still depends to a fixed timeout
and a fixed line out.
Well, if I get the test logic correctly it is supposed to test that
the agent blocks the port even when no client has connected yet.
Connecting to the agent and waiting for the event would change the
thing the test checks, actually.
You are right that the test should not attach a VM before launching the
second debuggee. Let's hope that 5000 * Utils.TIMEOUT_FACTOR works for
all testing machines.
Looks OK.
Thanks,
Shanliang
-JB-
Shanliang
Jaroslav Bachorik wrote:
Please, review the following test fix:
Issue : https://bugs.openjdk.java.net/browse/JDK-6791551
Webrev: http://cr.openjdk.java.net/~jbachorik/6791551/webrev.00
The fix prevents the situation when the first debuggee has not managed
to finish its intialization while the second one is started up thus
making the port available for the second debuggee and failing the test.
The patch is using the library methods to configure and launch the
debuggee and the test waits for the well known string to appear in the
first debuggee output before attempting to launch the second debuggee.
Thanks,
-JB-
