Hi Michael,
I added some comments as to what is the purpose of the latches and
barriers. Those comments alongwith the
comments describing the purpose of the handlers should make the
synchronization logic more clear. Let me know what
you think: http://cr.openjdk.java.net/~khazra/8017779/webrev.01/
Thanks,
Kurchi
On 7/17/2013 2:07 PM, Kurchi Hazra wrote:
On 7/17/2013 12:27 AM, Michael McMahon wrote:
On 16/07/13 20:11, Kurchi Hazra wrote:
Hi,
We have observed that test/java/net/Authenticator/B4769350.java
fails intermittently. Although not reproducible always,
the bug could be in the test/sun/net/www/httptest library that this
test uses. I have rewritten the test to use
com.sun.net.httpserver instead since we anyway want to move away
from using the httptest library.
I have used CyclicBarriers to mimic TestHttpServer.rendezvous() and
CountDownLatches to
mimic TestHttpServer.waitForCondition() and hopefully preserved the
rest of the logic in the test.
I have not seen the test failing after these changes.
Bug: http://bugs.sun.com/view_bug.do?bug_id=8017779
Webrev: http://cr.openjdk.java.net/~khazra/8017779/webrev.00/
Thanks,
Kurchi
Kurchi,
Since this is a fairly complicated test, and it's great to see it
being rewritten,
is there any possibility of adding some commentary that explains the
purpose
of the synchronization code. For instance, I can't see the purpose of
the call
on line 163 as it just blocks a thread that has already completed its
work
Michael
Hi Michael,
I have just preserved whatever logic the test originally had. The
specific instance you point out waits
for the T1b() handle to be executed for case 0 before moving forward.
But I guess it is hard to understand in a
glance and I'll add some more comments and get back with a new webrev.
Thanks,
Kurchi
--
-Kurchi
