Code Review Request: 8017779: java/net/Authenticator/B4769350.java fails

Kurchi Subhra Hazra kurchisubhra at gmail.com
Thu Jul 25 11:35:39 PDT 2013


Hi,

Did anyone have a chance to look at this?

Thanks,
Kurchi


On Thu, Jul 18, 2013 at 4:26 PM, Kurchi Hazra <
kurchi.subhra.hazra at oracle.com> wrote:

> 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/<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<http://bugs.sun.com/view_bug.do?bug_id=8017779>
>>>> Webrev: http://cr.openjdk.java.net/~**khazra/8017779/webrev.00/<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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130725/c19beb6f/attachment.html 


More information about the net-dev mailing list