[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[ https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053551#comment-17053551 ] Isaac commented on NETBEANS-58: --- The [underlying OpenJDK bug|https://bugs.openjdk.java.net/browse/JDK-8068184] has now closed with a fix version of Java 14. The fix has also been backported to Java 8. Can those experiencing the issue update to a fixed version of JRE and try again? > NB IDE or NB Platform freeze on startup (proxy with Negotiate auth) > --- > > Key: NETBEANS-58 > URL: https://issues.apache.org/jira/browse/NETBEANS-58 > Project: NetBeans > Issue Type: Bug > Components: platform - Proxy >Affects Versions: 8.2, 9.0, 11.0 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, > image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt > > > 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|https://netbeans.org/bugzilla/show_bug.cgi?id=248308]. > The problem arises because of the fix JDK folks applied as a consequence of > the reported [JDK-8032832 > bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. 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|https://bugs.openjdk.java.net/browse/JDK-8068184]. > h3. WHEN DOES IT HAPPEN? > 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). Therefore, 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. > h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG? > This bug in this ticket is characterized by the fact that you'll always be > able to find the following in your thread dump: > {noformat} >at > sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:) > - locked (a org.netbeans.ModuleManager$SystemClassLoader) > {noformat} > Note that the [Ctrl-Break > method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html] > of obtaining a thread dump is favoured over jstack and other methods. > h3. WHY DOES IT HAPPEN? > There will be a lock 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 v
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[ https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053551#comment-17053551 ] Isaac edited comment on NETBEANS-58 at 3/6/20, 4:22 PM: The [underlying OpenJDK bug|https://bugs.openjdk.java.net/browse/JDK-8068184] has now closed with a fix version of Java 14. The fix is going to be backported to Java 8. Let's see if the fix works. was (Author: isaac): The [underlying OpenJDK bug|https://bugs.openjdk.java.net/browse/JDK-8068184] has now closed with a fix version of Java 14. The fix has also been backported to Java 8. Can those experiencing the issue update to a fixed version of JRE and try again? > NB IDE or NB Platform freeze on startup (proxy with Negotiate auth) > --- > > Key: NETBEANS-58 > URL: https://issues.apache.org/jira/browse/NETBEANS-58 > Project: NetBeans > Issue Type: Bug > Components: platform - Proxy >Affects Versions: 8.2, 9.0, 11.0 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, > image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt > > > 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|https://netbeans.org/bugzilla/show_bug.cgi?id=248308]. > The problem arises because of the fix JDK folks applied as a consequence of > the reported [JDK-8032832 > bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. 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|https://bugs.openjdk.java.net/browse/JDK-8068184]. > h3. WHEN DOES IT HAPPEN? > 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). Therefore, 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. > h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG? > This bug in this ticket is characterized by the fact that you'll always be > able to find the following in your thread dump: > {noformat} >at > sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:) > - locked (a org.netbeans.ModuleManager$SystemClassLoader) > {noformat} > Note that the [Ctrl-Break > method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html] > of obtaining a thread dump is favoured over jstack and other methods. > h3. WHY DOES IT HAPPEN? > There will be a lock 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
[jira] [Comment Edited] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[ https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053551#comment-17053551 ] Isaac edited comment on NETBEANS-58 at 3/6/20, 4:23 PM: The [underlying OpenJDK bug|https://bugs.openjdk.java.net/browse/JDK-8068184] has now closed with a fix version of Java 14. The fix is going to be backported to Java 7, 8 and 11. Let's see if the fix works. was (Author: isaac): The [underlying OpenJDK bug|https://bugs.openjdk.java.net/browse/JDK-8068184] has now closed with a fix version of Java 14. The fix is going to be backported to Java 8. Let's see if the fix works. > NB IDE or NB Platform freeze on startup (proxy with Negotiate auth) > --- > > Key: NETBEANS-58 > URL: https://issues.apache.org/jira/browse/NETBEANS-58 > Project: NetBeans > Issue Type: Bug > Components: platform - Proxy >Affects Versions: 8.2, 9.0, 11.0 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, > image-2018-04-24-15-57-47-592.png, nb-freeze-dump.txt, netbeans.txt > > > 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|https://netbeans.org/bugzilla/show_bug.cgi?id=248308]. > The problem arises because of the fix JDK folks applied as a consequence of > the reported [JDK-8032832 > bug|https://bugs.openjdk.java.net/browse/JDK-8032832]. 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|https://bugs.openjdk.java.net/browse/JDK-8068184]. > h3. WHEN DOES IT HAPPEN? > 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). Therefore, 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. > h3. HOW DO I KNOW IF I'M AFFECTED BY EXACTLY THIS BUG? > This bug in this ticket is characterized by the fact that you'll always be > able to find the following in your thread dump: > {noformat} >at > sun.net.www.protocol.http.NegotiateAuthentication.isSupported(NegotiateAuthentication.java:) > - locked (a org.netbeans.ModuleManager$SystemClassLoader) > {noformat} > Note that the [Ctrl-Break > method|https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr019.html] > of obtaining a thread dump is favoured over jstack and other methods. > h3. WHY DOES IT HAPPEN? > There will be a lock 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 d