RFR 6791551: ExclusiveBind.java has a race condition (original) (raw)

Jaroslav Bachorik jaroslav.bachorik at oracle.com
Mon Feb 10 04:00:56 PST 2014

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

More information about the serviceability-dev mailing list