No simpler solution inside HTTP/SPNEGO?
--Max
----- peterhansson...@yahoo.com wrote:
> Hi
>
> I'm trying to fix a deadlock in NetBeans IDE and NetBeans Platform.
> The deadlock is a result of the fix for JDK-8032832 which introduced a
> lock on the classloader. Unfortunately this fix just introduces
> another bug (reported as JDK-8068184). I'm now soliciting advice from
> this list.
>
> The bug essentially causes NetBeans IDE (or applications build on
> NetBeans Platform) to freeze on startup if the site is using a proxy
> which uses 'Negotiate' auth scheme.
>
>
> The reason for the deadlock is straightforward:
>
> When doing SPNEGO exchange there's now (as a result of the fix) a lock
> on the classloader in NegotiateAuthentication.java:
>
>
> synchronized (loader) {
>
> return isSupportedImpl(hci);
>
> }
>
>
> Now, on Windows it is very likely that the TGT cannot be obtained and
> for this reason the Authenticator gets invoked. In fact it is almost
> certain that a Java SE client application on Windows engaging in
> SPNEGO will have to invoke the Authenticator and for this reason the
> freeze affects A LOT of people.
>
>
> The Authenticator will get invoked WHILE there's a lock on the
> classloader. NetBeans' Authenticator will prompt the user for
> credentials using a dialog. Since NetBeans is Swing based this will
> happen Swing's EDT. Bringing up a dialog will almost inevitably
> require classloading (especially in the beginning of an application's
> life) and the EDT will then get stuck because the classloader is
> locked and because NetBeans' classloader also uses locking. This is
> what causes the freeze. The network task thread has a lock on the
> classloader but at the same time it is waiting for the user to respond
> to a dialog but this will never happen because the UI thread is stuck
> on class loading.
>
>
> I see at least two avenues that can be pursued:
>
>
> 1. Fix in JDK: The fix introduced in JDK-8032832, putting a lock on
> the classloader, seems to me to have lots of unwanted side-effects.
> Was this really the only way to fix the reported issue? Could this
> fix be revisited?
>
> 2. Fix in NetBeans: I'm not an expert on NetBeans' classloader. It
> seems to be me to be implemented at a time when locking on the
> classloader itself (using syncronized loadClass() method) was the
> general recommendation. But with the changes done in Java 7 to the
> default classloader the recommendations changed.
>
> http://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.htmlSo
> a possible solution may be to change the NetBeans classloader to be
> more granular on syncronization along the lines of what the standard
> classloader does as of Java 7. I don't know if this is feasible at
> all. The NetBeans classloader(s) is really the magic sauce behind
> NetBeans' much acclaimed module system which underpins *everything* on
> the platform. So, I guess, less the original authors, there just isn't
> many people who would dare touch that piece of code.
>
>
> and there may be more solutions that I have overlooked. :-)
>
>
>
> Pls advice.
>
> /Peter
