Looks good! Thanks, /Staffan
On 10 feb 2014, at 13:00, Jaroslav Bachorik <jaroslav.bacho...@oracle.com> wrote: > On 4.2.2014 16:07, shanliang wrote: >> 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. > > Hopefully it should. 5 seconds to start the debugee under normal > circumstances sounds more than enough. For the exceptional circumstances the > TIMEOUT_FACTOR should be properly tuned. We will see. > > >> Looks OK. > > Thanks! > > May I get an official reviewer to take a look at this, please? > > -JB- > >> >> 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-
