RFR: 8223714: HTTPSetAuthenticatorTest could be made more resilient

Jaikiran Pai jai.forums2013 at gmail.com
Mon Sep 2 11:23:56 UTC 2019


Hello Vyom, Daniel,

On 02/09/19 3:00 PM, Daniel Fuchs wrote:
> Hi,
>
> On 02/09/2019 05:29, Vyom Tewari26 wrote:
>>>     2-> i think super.stop() should be the first line in the
>>>     overridden stop method.
>>
>>     I had thought of this when I introduced the change. However, I felt
>>     that it's better to set the stop=true before calling the
>>     super.stop(), since this way the other thread gets "notified" a bit
>>     early that it doesn't have to accept any more connections, thus it
>>     doesn't have to first go into a blocking accept() and then get
>>     thrown an exception (when the stop() method does a ss.close()) and
>>     then go and check if it was asked to stop. Of course, this doesn't
>>     guarantee that the other thread will always benefit from this (since
>>     it might already be in a blocking accept()), but at least it does
>>     present the other thread a chance >
>> My only worry was what if super.stop() fails and throws exception but
>> in super.stop() we are catching/ignoring the exception and logging
>> the trace to system.out.
>
> I'd also prefer setting `stop` to  true before calling super.stop() for
> the reason that Jaikiran states. That said maybe a better implementation
> could be:
>
>     try (var toClose = ss;) {
>         stop = true;
>         super.stop();
>     } catch (IOException ex) {
>         ...
>     }
>
> this way we can be sure that ss.close will be closed
> even if super.stop() throws something (which shouldn't
> happen but who knows?)

This does look better. I have updated the code to use this construct and
the new webrev is at
http://cr.openjdk.java.net/~jpai/webrev/8223714/3/webrev/ (only the
stop() method code has changed compared to previous webrev).

-Jaikiran



More information about the net-dev mailing list