The fix looks fine. You might want to remove the cache-related words from the comment of the new isSupported method.
--Max On Mar 25, 2014, at 18:48, Anton Litvinov <anton.litvi...@oracle.com> wrote: > Hello Chris, > > Thank you very much for review of this fix and for addressing the review > request to the second possible reviewer. I am looking forward to receiving > any response from Weijun Wang. Also I would like to inform you that jtreg > regression tests specified below (both open and internal proprietary) were > run on all 4 supported platforms: MS Windows, Linux, Solaris, OS X. The > results of regression tests were almost identical on on all the platforms, > however, no negative changes introduced by the fix were found. > > Executed regression tests: > - "jdk/test/java/net" > - "jdk/test/sun/net" > > Thank you, > Anton > > On 3/24/2014 8:38 PM, Chris Hegarty wrote: >> Hi Anton, >> >> I don't have any objections to this, but Max is the original author of this >> code and may want to take a closer look. >> >> -Chris. >> >> On 20/03/14 14:08, Anton Litvinov wrote: >>> Hello, >>> >>> Could you please review the following fix for the bug, which consists in >>> a deadlock between 2 threads sharing the same instance of >>> "java.net.URLClassLoader" as the context class loader, calling >>> "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" method >>> and loading a class file from the web server with the enabled >>> "Negotiate" authentication. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8032832 >>> Webrev: http://cr.openjdk.java.net/~alitvinov/8032832/jdk9/webrev.00 >>> >>> The fix is based on supplementing the method >>> "sun.net.www.protocol.http.NegotiateAuthentication.isSupported" with the >>> code locking on the instance of the class loader before existing locking >>> on the class "sun.net.www.protocol.http.NegotiateAuthentication". >>> >>> Thank you, >>> Anton >
