netbeans-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hansson (JIRA)" <>
Subject [jira] [Created] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
Date Sat, 16 Sep 2017 11:27:00 GMT
Peter Hansson created NETBEANS-58:

             Summary: NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
                 Key: NETBEANS-58
             Project: NetBeans
          Issue Type: Bug
          Components: platform - Proxy
    Affects Versions: 8.2, 9.0
         Environment: Primarily Windows.
            Reporter: Peter Hansson

When any network operation is performed, such as attempting to contact NetBeans Update Center,
the application (IDE or Platform) may freeze.Users will typically experience this on startup.
It was reported in old bug tracker as [bug 248308|].

The problem arises because of the fix JDK folks applied as a consequence of the reported [JDK-8032832
bug|]. This fix wasn't very clever IMO: it
puts a lock on the classloader, thus introducing a range of other problems, one of them being
that NetNeans IDE or NetBeans Platform will likely freeze on startup when it attempts a network
operation. The fact that their fix made things worse (while no doubt fixing the original issue)
has been reported as [JDK-8068184|].

As the lock is introduced for authentication of type 'Negotiate' it of course only happens
if there's a network proxy on the path which uses this type of authentication. Also known
as SPNEGO. This form of authentication is in my experience very common in corporate networks,
in particular those that base themselves on the Microsoft stack. But a person on Oracle's
own internal network, such as a JDK developer, is most likely not exposed to it. :-)

There's another condition for it to happen: The JRE runtime must be unable to provide 'credentials'
(a Kerberos token) to the network proxy on its own. SPNEGO is really designed to be seamless
and promptless. Support for it was added in Java 6. But later on Microsoft tightened the desktop
security around obtaining the so-called 'session token' and the JDK folks were never able
to work around this (unlike the makers of Chrome, FF, Opera, etc) so in real-life, SPNEGO
in the JRE on Windows is no longer promptless:  it will be forced to ask the user for credentials,
thus negating the idea of SPNEGO. It is the prompting which causes the freeze. SPNEGO on Mac
OS X and Linux is most likely working just fine and the bug will never be experienced.


This bug in this ticket is characterized by the fact that you'll always be able to find the
following in your thread dump:

        - locked <OBJECTID> (a org.netbeans.ModuleManager$SystemClassLoader)


Note that the [Ctrl-Break method|]
of obtaining a thread dump is favoured over jstack and other methods.

There will be a lock on held on the classloader object when the JRE's registered  Authenticator
is invoked. If the Authenticator does work on another thread, that other thread has a need
for some classloading and the current thread needs to wait for the result of that thread,
then bum!, there's a deadlock between the two threads. This means the lock on the classloader
will never be released and it will ultimately affect other threads, such as the AWT dispatch
thread (aka Swing EDT) which will then also lock. Then you have what the user experiences
as a freeze.

The NB Platform's own Authenticator, {{NbAuthenticator}}, does exactly what I described and
will thus be triggering the deadlock. More precisely it will happen when NbAuthenticator calls
Keyring. Does this mean the NbAuthenticator does something wrong?  No, of course it
doesn't. The real problem is the lock on the classloader. It is actually virtually impossible
to design an Authenticator which doesn't trigger this problem. You cannot predict when classloading
is needed. In fact it is very likely to be needed when application is still not
"warm", i.e. during startup.


If on Windows: Setting the following registry key:


to {{true}} will allow the JRE to obtain the session key, thus the JDK's HTTP classes will
have no need to invoke Authenticator, thus deadlock will not happen. But there's zero chance
in a million that a corporate network administrator will allow this change. After all, Microsoft
introduced the tightened security for a reason and the admin will rightly ask why only the
JRE needs this and not Chrome, IE, FF, Opera and so on?

Convice the JDK folks that they've made a mess of it with this lock. I've pursued this avenue
too. I've done that on the JDK security-dev mailing list. I've pointed to similar bug tickets
for Eclipse IDE and IDEA and I got the attention of Weijun Wang ("Max") of Oracle who promised
we would look at it. But to be honest the JDK people have a lot of other things on their plate
and a fix will take some time.


Re-design the Authenticator in the Platform. As I cannot change the code in NB itself, I've
created a workaround as a plugin. The recipe is described in [Comment 44|]
on the original NB bug ticket. This is really a workaround, not a fix. It will simply give
up on attempting to obtain credentials if it discovers that it is likely to be in this deadlock
scenario. Thus it leaves the application with no outbound network connectivity but it is still
better than the freeze.
It also alerts the user to the situation using a bubble notification. 


It may help to set proxy username/password _explicitly _in the NB's Options panel. But this
is not a solution I recommend. It means you must put your AD password into NetBeans IDE Options.
It will of course be static so once your AD password changes then you must remember to change
there as well. And for the user to configure this, it requires that he can actually start
the IDE or Platform app in the first place ... which is often not the case because of the


IMHO #3 is the most attractive solution for now. It doesn't exclude the user still doing #1
or #4 to get full benefit. The real solution is of course #2.

.. and the very best solution long term is if JDK would have same support for SPNEGO on Windows
as does 'regular' applications such as Chrome, FF, Opera, IE, Edge, etc. Then we wouldn't
have the problem in the first place. This has been discussed intensively over the last 7-8
years but there's a somewhat religious tug of war between Sun/Oracle and Microsoft on the
matter. The problem can be solved if the JDK would base itself on the Win32 SSPI api in this
area, rather than the long-time deprecated Win32 LsaCallAuthenticationPackage API. We are
getting slightly off topic here and not appropriate for a bug ticket. :-)

This message was sent by Atlassian JIRA

View raw message