RFR 6791551: ExclusiveBind.java has a race condition

[Jaroslav Bachorik]

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-
>>>
>>
>