[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
[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=17022951#comment-17022951 ] guillaume canivet edited comment on NETBEANS-58 at 1/24/20 4:36 PM: I Experience a similar issue, in my case the freeze is not during startup, indeed, within my NB platform based application (RELEASE112), I have a module able to perform REST call (trigger by user click), and I am behind a corporate transparent proxy (with Kerberos token). Note: using Windows 10, Java 8 and NetBeans Version: RELEASE112. The freeze only occurred when the Kerberos token need to be refresh (or it seems). Also in our case: *#1* and *#4* does not work, freeze still occurred. Only *#3* is working (rebuild with RELEASE112). The behavior of the *#3* is fine with us, but I really want to have an official NetBeans fix. Is there something we can do to have an official NetBeans fix? was (Author: guillaumecanivet): I Experience a similar issue, in my case the freeze is not during startup, indeed, within my NB platform based application (RELEASE112), I have a module able to perform REST call (trigger by user click), and I am behind a corporate transparent proxy (with Kerberos token). Note: using Windows 10, Java 8 and NetBeans Version: RELEASE112. The freeze only occurred when the Kerberos token need to be refresh (or it seems). Also in our case: *#1* and *#4* does not work, freeze still occurred. Only *#3* is working (rebuild with RELEASE112). The behavior of the *#3* is fine with us, but I really want to have an official NetBeans fix. Is there something we can do to have an official NetBeans fix? > 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
[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=17022951#comment-17022951 ] guillaume canivet edited comment on NETBEANS-58 at 1/24/20 4:35 PM: I Experience a similar issue, in my case the freeze is not during startup, indeed, within my NB platform based application (RELEASE112), I have a module able to perform REST call (trigger by user click), and I am behind a corporate transparent proxy (with Kerberos token). Note: using Windows 10, Java 8 and NetBeans Version: RELEASE112. The freeze only occurred when the Kerberos token need to be refresh (or it seems). Also in our case: *#1* and *#4* does not work, freeze still occurred. Only *#3* is working (rebuild with RELEASE112). The behavior of the *#3* is fine with us, but I really want to have an official NetBeans fix. Is there something we can do to have an official NetBeans fix? was (Author: guillaumecanivet): I Experience a similar issue, in my case the freeze is not during startup, indeed, within my NB platform based application (RELEASE112), I have a module able to perform REST call (trigger by user click), and I am behind a corporate transparent proxy (with Kerberos token). Note: using Java 8 and NetBeans Version: RELEASE112. The freeze only occurred when the token need to be refresh (or it seems). Also in our case: *#1* and *#4* does not work, freeze still occurred. Only *#3* is working (rebuild with RELEASE112). The behavior of the *#3* is fine with us, but I really want to have an official NetBeans fix. Is there something we can do to have an official NetBeans fix? > 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://doc
[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=17022951#comment-17022951 ] guillaume canivet edited comment on NETBEANS-58 at 1/24/20 4:23 PM: I Experience a similar issue, in my case the freeze is not during startup, indeed, within my NB platform based application (RELEASE112), I have a module able to perform REST call (trigger by user click), and I am behind a corporate transparent proxy (with Kerberos token). Note: using Java 8 and NetBeans Version: RELEASE112. The freeze only occurred when the token need to be refresh (or it seems). Also in our case: *#1* and *#4* does not work, freeze still occurred. Only *#3* is working (rebuild with RELEASE112). The behavior of the *#3* is fine with us, but I really want to have an official NetBeans fix. Is there something we can do to have an official NetBeans fix? was (Author: guillaumecanivet): I Experience a similar issue, in my case the freeze is not during startup, indeed I have a module within the studio (RCP) able to perform REST call (trigger by user click), and I am behind a corporate transparent proxy (with Kerberos token). Note: using Java 8 and NetBeans Version: RELEASE112. The freeze only occurred when the token need to be refresh (or it seems). Also in our case: *#1* and *#4* does not work, freeze still occurred. Only *#3* is working (rebuild with RELEASE112). The behavior of the *#3* is fine with us, but I really want to have an official NetBeans fix. Is there something we can do to have an official NetBeans fix? > 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/troublesh
[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=16857594#comment-16857594 ] jmborer edited comment on NETBEANS-58 at 6/6/19 12:27 PM: -- @phansson: do you plan to recompile your plugins for NB 11 and release them on the plugin center? The 8.2 plugins could have been compatible if they haven't been linked to implementation version of certain modules. phansson had probably to do it to get access to classes that are not publicly accessible otherwise. I ran several times into similar issues with our NB platform based application. I often regret that the exposure policy in NB is often more closed than open. IMHO this over protects NB "internals" a little too much. I would have preferred a policy based on greater openness and trust. This would have greatly facilitate my life. was (Author: jmborer): @phansson: do you plan to recompile your plugins for NB 11 and release them on the plugin center? The 8.2 plugins could have been compatible if they haven't been linked to implementation version of certain modules. phansson had probably to do it to get access to classes that are not publicly accessible otherwise. I ran several times into similar issues with our NB platform based application. I often regret that the exposure policy is NB is more often closed than public. IMHO this over protect NB "internals" a little too much. I would have preferred a policy based on greater openness and trust. This would have greatly facilitate my life. > 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 othe
[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=16857594#comment-16857594 ] jmborer edited comment on NETBEANS-58 at 6/6/19 12:26 PM: -- @phansson: do you plan to recompile your plugins for NB 11 and release them on the plugin center? The 8.2 plugins could have been compatible if they haven't been linked to implementation version of certain modules. phansson had probably to do it to get access to classes that are not publicly accessible otherwise. I ran several times into similar issues with our NB platform based application. I often regret that the exposure policy is NB is more often closed than public. IMHO this over protect NB "internals" a little too much. I would have preferred a policy based on greater openness and trust. This would have greatly facilitate my life. was (Author: jmborer): @phansson: do you plan to recompile your plugins for NB 11 and release them on the plugin center? The 8.2 plugins could have been compatible if they haven't been linked to implementation version of certain modules. phansson had probably to do it to get access to classes that are not publicly accessible otherwise. I ran several times into similar issues with our NB platform based application. I often regret that the exposure policy is NB is more often closed than public. IMHO this over protect NB "internals" a little too much. I would have preferred a policy based on greater openness and trust. > 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
[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=16857508#comment-16857508 ] jmborer edited comment on NETBEANS-58 at 6/6/19 10:54 AM: -- Not sure to understand how the PR is solving the issue. First, it seems to partly solve it by providing SPI for custom Authenticator and secondly I don't understand in which state the PR currently is. was (Author: jmborer): Not sure to understand how the PR is solving the issue. Fist, it seems to partly solve it by providing SPI for custom Authenticator and secondly I don't understand in which state the PR currently is. > 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 i
[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=16857437#comment-16857437 ] jmborer edited comment on NETBEANS-58 at 6/6/19 8:48 AM: - May be it is a left over when I migrated my preferences from 8.2 to 11.0 I disabled the 8.2 plugins portal as well now. I opened up again the start page and can observe queries to [http://www.netbeans.org/news.xml] Isn't it the RSS feed? When you navigate the start page it triggers as well GET to http://netbeans.org/demos.xml was (Author: jmborer): May be it is a left over when I migrated my preferences from 8.2 to 11.0 I disabled the 8.2 plugins portal as well now. I opened up again the start page and can observe queries to [http://www.netbeans.org/news.xml] Isn't it the RSS feed? > 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 b
[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=16857431#comment-16857431 ] jmborer edited comment on NETBEANS-58 at 6/6/19 8:40 AM: - Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [ http://netbeans-vm.apache.org/uc/11.0/updates.xml.gz?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a_90e7342f-955b-4cc6-8e15-39e4810b37c2|http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] [https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz] Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. was (Author: jmborer): Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. > 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 i
[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=16857431#comment-16857431 ] jmborer edited comment on NETBEANS-58 at 6/6/19 8:38 AM: - Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: [http://www.netbeans.org/news.xml] [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. When I open some of my projects the IDE triggers calls to: [http://plugins.netbeans.org/nbpluginportal/updates/11.0/catalog.xml.gz] https://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz Not sure why opening projects trigger check of update center. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. was (Author: jmborer): Hmm. That is a very good question. I don't know if Tilman Hausherr is running into this issue because of the start page or if it is related to other network requests. The start page is just another trigger for network requests. For example, when I start my IDE where the start page is already disabled (unchecked "show on startup") and no projects open, NB still triggers network requests to: http://www.netbeans.org/news.xml [http://www.netbeans.org/mtmo.xml?unique=08be841b7-fc8c-4d4c-8ab8-940d08493e7a] These request can lead to the deadlock of the IDE. What is particularly annoying with this issue is its unpredictability. It can bite you or not. For example our new very faster PCs with SSDs are more likely (not to say systematically) to run into this issue where my older machine seems not to be affected. This is pure luck. > 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 caus
[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=16857412#comment-16857412 ] Geertjan Wielenga edited comment on NETBEANS-58 at 6/6/19 8:20 AM: --- So, if there was a switch to cause the Welcome screen not to be shown at startup or the module providing the Welcome screen to be disabled at startup, that would solve this? was (Author: geertjanwielenga): So, if there was a switch to cause the Welcome screen not to be shown or the module providing the Welcome screen to be disabled, that would solve this? > 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 t
[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=16857390#comment-16857390 ] jmborer edited comment on NETBEANS-58 at 6/6/19 8:11 AM: - I confirm that this still happens with NB 11. As I said before, not the best advertisement for NB when you try to convince people to adopt it. When you install NB, it will by default open the welcome "start" page which triggers network requests. was (Author: jmborer): I confirm that this still happens with NB 11. I find this really an important issue. When it bites you (my colleagues for example), it is not the best user experience you can expect from such an amazing IDE. My colleagues were quite upset and immediately thought to change their IDE for an alternative. Hopefully this only happens in specific working environment, but still, not the best promotion for NB... When you install NB, it will by default open the welcome "start" page which triggers network requests. I still don't understand why this issue can't be fixed in NB. If I remember well when I hunted down the issue, it is the asynchronous request to the Keyring with another thread that deadlock each other... > 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!, t
[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=16857390#comment-16857390 ] jmborer edited comment on NETBEANS-58 at 6/6/19 7:58 AM: - I confirm that this still happens with NB 11. I find this really an important issue. When it bites you (my colleagues for example), it is not the best user experience you can expect from such an amazing IDE. My colleagues were quite upset and immediately thought to change their IDE for an alternative. Hopefully this only happens in specific working environment, but still, not the best promotion for NB... When you install NB, it will by default open the welcome "start" page which triggers network requests. I still don't understand why this issue can't be fixed in NB. If I remember well when I hunted down the issue, it is the asynchronous request to the Keyring with another thread that deadlock each other... was (Author: jmborer): I confirme that this still happens with NB 11. I find this really an important issue. When it bites you (my colleagues for example), it is not the best user experience you can expect from such an amazing IDE. My colleagues were quite upset and immediately thought to change their IDE for an alternative. Hopefully this only happens in specific working environment, but still, not the best promotion for NB... When you install NB, it will by default open the welcome "start" page which triggers network requests. I still don't understand why this issue can't be fixed in NB. If I remember well when I hunted down the issue, it is the asynchronous request to the Keyring with another thread that deadlock each other... > 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:/
[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=16451670#comment-16451670 ] lbruun edited comment on NETBEANS-58 at 4/26/18 5:24 AM: - Geertjan Wielenga wrote: {quote}It is super critical in a specific subset of scenarios, I for one have never (working within and without a corporate proxy) have never encountered it, as far as I am aware. Has this problem always been in NetBeans and is the only solution "to implement more fine grained classloaders" {quote} At least two questions there: # *Why you've never encountered it?* In my experience sites that deploy a proxy with Negotiate/Kerberos are more often than not MS shops, i.e. they use AD as the base of everything. Is that really where you've been? Also you have to use a Windows workstation for the problem to occur (due to Oracle's historical resistance to implement native support for SSPI on Windows ... it is a long story, but in essence in means that the Kerberos implementation in Java SE for Windows is extremely crippled when used in desktop scenarios : Java on Windows cannot automatically obtain a Kerberos ticket which means it is forced to invoke the Authenticator. On Mac OS X and Linux this would all be seamless, no need to invoke the Authenticator and therefore no deadlock). # *Has the problem always existed?* No, not always. The problem was introduced as a consequence of a [JDK bug fix|https://bugs.openjdk.java.net/browse/JDK-8032832] which was first introduced in Java 8u25 and later backported. This fix works fine for the JDK itself because their classloaders use the [Java 7 (and onwards) new functionality for classloaders|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html]. The NB Platform doesn't. The JDK folks phrase it like this: "Synchronization in the {{ClassLoader}} class was previously heavy-handed, or in technical terms, _not sufficiently granular_. A request to load a class synchronized on the entire {{ClassLoader}} object, which made it prone to deadlock.". That is exactly the problem in the NB Platform's classloaders. (discussed in NETBEANS-106). In summary: There are a number of conditions that must exist for the freeze bug to surface for a user: # The site uses a proxy which uses Negotiate/Kerberos for authentication. As this method was largely 'invented' by Microsoft and later standardized as an RFC, you see this very often on MS centric sites. (it is essentially the same as what Microsoft cleverly refers to as "Windows Integrated Authentication", clever because it leads people to be believe that this form of seamless authentication is only possible on Windows) # Workstation is Windows (not Mac OS X, not Linux) * # Lastly, if the Platform or IDE user experiences the bug "without having touched anything" (which is quite likely) then it is because the Platform automatically picks up the proxy from the OS/InternetExplorer settings. Hence users will just experience that the Platform app or IDE hangs the first time they ever try to use it. Ouch! Honestly, I think one of the reasons why the problem gets little traction is because both JDK developers and NB developers have removed themselves somewhat from parts of their user base by using Mac OS X or Linux as their desktop as opposed to Windows. I'm partly guilty myself :P *) I suppose theoretically it can happen on Mac OS X and Linux too if you have a defunct Kerberos configuration. It is just that on Windows the Java/Kerberos stack is by default "defunct" (as explained) was (Author: lbruun): Geertjan Wielenga wrote: {quote}It is super critical in a specific subset of scenarios, I for one have never (working within and without a corporate proxy) have never encountered it, as far as I am aware. Has this problem always been in NetBeans and is the only solution "to implement more fine grained classloaders" {quote} At least two questions there: # *Why you've never encountered it?* In my experience sites that deploy a proxy with Negotiate/Kerberos are more often than not MS shops, i.e. they use AD as the base of everything. Is that really where you've been? Also you have to use a Windows workstation for the problem to occur (due to Oracle's historical resistance to implement native support for SSPI on Windows ... it is a long story, but in essence in means that the Kerberos implementation in Java SE for Windows is extremely crippled when used in desktop scenarios : Java on Windows cannot automatically obtain a Kerberos ticket which means it is forced to invoke the Authenticator. On Mac OS X and Linux this would all be seamless, no need to invoke the Authenticator and therefore no deadlock). # *Has the problem always existed?* No, not always. The problem was introduced as a consequence of a [JDK bug fix|https://bugs.openjdk.java.net/browse/JDK-803
[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=16451798#comment-16451798 ] Geertjan Wielenga edited comment on NETBEANS-58 at 4/25/18 7:41 AM: [~jmborer]: "Conclusion: @Netbeans team, please, bundle ProxySelector and Netbeans Authenticator with the NB platform!!" OK, is this the following, by [~phansson], or are you referring to something different? [https://bitbucket.org/phansson/netbeansnetworkauthenticator] [https://bitbucket.org/phansson/netbeansnetworkauthenticator/wiki/JDK-8068184%20Workaround] Also note that YOU are the NetBeans team, too. :) I.e., please do provide a PR or state what you are specifically asking for here. was (Author: geertjanwielenga): [~jmborer]: "Conclusion: @Netbeans team, please, bundle ProxySelector and Netbeans Authenticator with the NB platform!!" OK, is this the following, by [~phansson], or are you referring to something different? [https://bitbucket.org/phansson/netbeansnetworkauthenticator] [https://bitbucket.org/phansson/netbeansnetworkauthenticator/wiki/JDK-8068184%20Workaround] > 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 > 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
[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=16450130#comment-16450130 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 4:03 PM: -- I did a very interesting finding. Re-installed NB 8.2 with JDK 1.8-172 on Windows 7. Installed ProxySelectorPlugin + Authenticator and selected System proxy. Then using the registry I added: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters] "allowtgtsessionkey"=dword:0001 and not what is explained here: [https://support.microsoft.com/en-us/help/308339/registry-key-to-allow-session-keys-to-be-sent-in-kerberos-ticket-grant] Then I restarted NB IDE: it froze at startup during ~60 s. and also on a regular base during its life (retrieving Maven index for example), BUT I didn't get errors reported by the Authentication plugin. Then I deleted the REG entry above, restarted the IDE and it did't freeze, but I got !image-2018-04-24-15-57-47-592.png! So SPNEGO seems somehow to work with the setting above, but it will make your IDE/APP freeze regularly a quite long time. Conclusion: @Netbeans team, please, bundle ProxySelector and Netbeans Authenticator with the NB platform!! was (Author: jmborer): I did a very interesting finding. Re-installed NB 8.2 with JDK 1.8-172 on Windows 7. Installed ProxySelectorPlugin + Authenticator and selected System proxy. Then using the registry I added: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters] "allowtgtsessionkey"=dword:0001 and not what is explained here: [https://support.microsoft.com/en-us/help/308339/registry-key-to-allow-session-keys-to-be-sent-in-kerberos-ticket-grant] Then I restarted NB IDE: it froze at startup during ~60 s. and also on a regular base during its life (retrieving Maven index for example), BUT I didn't get errors reported by the Authentication plugin. Then I deleted the REG entry above, restarted the IDE and it did't freeze, but I got !image-2018-04-24-15-57-47-592.png! So SPNEGO seems somehow to work with the setting above, but it will make your IDE/APP freeze regularly a quite long time. Conclusion: bundle ProxySelector and NBAuthenticator > 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 > 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 >
[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=16450130#comment-16450130 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 4:02 PM: -- I did a very interesting finding. Re-installed NB 8.2 with JDK 1.8-172 on Windows 7. Installed ProxySelectorPlugin + Authenticator and selected System proxy. Then using the registry I added: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters] "allowtgtsessionkey"=dword:0001 and not what is explained here: [https://support.microsoft.com/en-us/help/308339/registry-key-to-allow-session-keys-to-be-sent-in-kerberos-ticket-grant] Then I restarted NB IDE: it froze at startup during ~60 s. and also on a regular base during its life (retrieving Maven index for example), BUT I didn't get errors reported by the Authentication plugin. Then I deleted the REG entry above, restarted the IDE and it did't freeze, but I got !image-2018-04-24-15-57-47-592.png! So SPNEGO seems somehow to work with the setting above, but it will make your IDE/APP freeze regularly a quite long time. Conclusion: bundle ProxySelector and NBAuthenticator was (Author: jmborer): I did a very interesting finding. Re-installed NB 8.2 with JDK 1.8-172 on Windows 7. Installed ProxySelectorPlugin + Authenticator and selected System proxy. Then using the registry I added: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters] "allowtgtsessionkey"=dword:0001 and not what is explained here: https://support.microsoft.com/en-us/help/308339/registry-key-to-allow-session-keys-to-be-sent-in-kerberos-ticket-grant Then I restarted NB IDE: it froze at startup during ~60 s. and also on a regular base during its life (retrieving Maven index for example), BUT I didn't get errors reported by the Authentication plugin. Then I deleted the REG entry above, restarted the IDE and it did't freeze, but I got !image-2018-04-24-15-57-47-592.png! So SPNEGO seems somehow to work with the setting above, but it will make your IDE/APP freeze regularly a quite long time. > 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 > 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 b
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 3:24 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#ff}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock {color:#ff}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {noformat} "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:587) at sun.security.jgss.GSSUtil.login(GSSUtil.java:258) at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330) at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122) at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187) at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) at sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882) at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 3:05 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#ff}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock {color:#ff}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {noformat} "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:587) at sun.security.jgss.GSSUtil.login(GSSUtil.java:258) at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330) at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122) at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187) at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) at sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882) at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:35 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#ff}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock {color:#ff}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {noformat} "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:587) at sun.security.jgss.GSSUtil.login(GSSUtil.java:258) at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330) at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122) at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187) at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) at sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882) at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:33 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#ff}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock {color:#ff}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {noformat} "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:587) at sun.security.jgss.GSSUtil.login(GSSUtil.java:258) at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330) at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122) at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187) at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) at sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882) at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:27 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#ff}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock {color:#ff}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {noformat} "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:587) at sun.security.jgss.GSSUtil.login(GSSUtil.java:258) at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330) at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122) at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187) at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) at sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882) at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:26 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#ff}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock {color:#ff}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {noformat} "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:587) at sun.security.jgss.GSSUtil.login(GSSUtil.java:258) at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330) at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122) at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187) at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) at sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882) at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:18 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#ff}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock {color:#ff}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {noformat} "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:587) at sun.security.jgss.GSSUtil.login(GSSUtil.java:258) at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330) at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122) at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187) at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) at sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882) at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248)
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:16 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#ff}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock {color:#ff}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {noformat} "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755) at javax.security.auth.login.LoginContext.access$000(LoginContext.java:195) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682) at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) at javax.security.auth.login.LoginContext.login(LoginContext.java:587) at sun.security.jgss.GSSUtil.login(GSSUtil.java:258) at sun.security.jgss.krb5.Krb5Util.getTicket(Krb5Util.java:158) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:335) at sun.security.jgss.krb5.Krb5InitCredential$1.run(Krb5InitCredential.java:331) at java.security.AccessController.doPrivileged(Native Method) at sun.security.jgss.krb5.Krb5InitCredential.getTgt(Krb5InitCredential.java:330) at sun.security.jgss.krb5.Krb5InitCredential.getInstance(Krb5InitCredential.java:145) at sun.security.jgss.krb5.Krb5MechFactory.getCredentialElement(Krb5MechFactory.java:122) at sun.security.jgss.krb5.Krb5MechFactory.getMechanismContext(Krb5MechFactory.java:187) at sun.security.jgss.GSSManagerImpl.getMechanismContext(GSSManagerImpl.java:224) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:212) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) at sun.security.jgss.spnego.SpNegoContext.GSS_initSecContext(SpNegoContext.java:882) at sun.security.jgss.spnego.SpNegoContext.initSecContext(SpNegoContext.java:317) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:248) at sun.security.jgss.GSSContextImpl.initSecContext(GSSContextImpl.java:179) at sun.net.www.protocol.http.spnego.NegotiatorImpl.init(NegotiatorImpl.java:108) at sun.net.www.protocol.http.spnego.NegotiatorImpl.(NegotiatorImpl.java:117) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Meth
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:08 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#ff}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock {color:#ff}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {noformat} "org.netbeans.api.keyring.Keyring" #26 daemon prio=1 os_prio=-2 tid=0x19593000 nid=0x1640 waiting for monitor entry [0x2655e000] java.lang.Thread.State: BLOCKED (on object monitor) at org.netbeans.ModuleManager$SystemClassLoader.getResourcesImpl(ModuleManager.java:708) - waiting to lock <0xc0d64370> (a org.netbeans.ModuleManager$SystemClassLoader) at org.netbeans.ProxyClassLoader.getResources(ProxyClassLoader.java:390) at org.openide.util.lookup.MetaInfServicesLookup.search(MetaInfServicesLookup.java:205) at org.openide.util.lookup.MetaInfServicesLookup.beforeLookup(MetaInfServicesLookup.java:156) at org.openide.util.lookup.MetaInfServicesLookup.beforeLookupResult(MetaInfServicesLookup.java:135) at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:483) at org.openide.util.lookup.ProxyLookup$R.initResults(ProxyLookup.java:390) at org.openide.util.lookup.ProxyLookup$R.myBeforeLookup(ProxyLookup.java:673) at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:553) at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:513) at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:509) at org.openide.util.Lookup.lookupAll(Lookup.java:312) at org.netbeans.api.keyring.Keyring.provider(Keyring.java:89) - locked <0xf0525f68> (a java.lang.Class for org.netbeans.api.keyring.Keyring) at org.netbeans.api.keyring.Keyring.readImpl(Keyring.java:105) - locked <0xf0525f68> (a java.lang.Class for org.netbeans.api.keyring.Keyring) at org.netbeans.api.keyring.Keyring.access$100(Keyring.java:75) at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:128) at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:125) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443) at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68) at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058) "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.Deleg
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:06 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#ff}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock {color:#ff}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {code:java} "org.netbeans.api.keyring.Keyring" #26 daemon prio=1 os_prio=-2 tid=0x19593000 nid=0x1640 waiting for monitor entry [0x2655e000] java.lang.Thread.State: BLOCKED (on object monitor) at org.netbeans.ModuleManager$SystemClassLoader.getResourcesImpl(ModuleManager.java:708) - waiting to lock <0xc0d64370> (a org.netbeans.ModuleManager$SystemClassLoader) at org.netbeans.ProxyClassLoader.getResources(ProxyClassLoader.java:390) at org.openide.util.lookup.MetaInfServicesLookup.search(MetaInfServicesLookup.java:205) at org.openide.util.lookup.MetaInfServicesLookup.beforeLookup(MetaInfServicesLookup.java:156) at org.openide.util.lookup.MetaInfServicesLookup.beforeLookupResult(MetaInfServicesLookup.java:135) at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:483) at org.openide.util.lookup.ProxyLookup$R.initResults(ProxyLookup.java:390) at org.openide.util.lookup.ProxyLookup$R.myBeforeLookup(ProxyLookup.java:673) at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:553) at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:513) at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:509) at org.openide.util.Lookup.lookupAll(Lookup.java:312) at org.netbeans.api.keyring.Keyring.provider(Keyring.java:89) - locked <0xf0525f68> (a java.lang.Class for org.netbeans.api.keyring.Keyring) at org.netbeans.api.keyring.Keyring.readImpl(Keyring.java:105) - locked <0xf0525f68> (a java.lang.Class for org.netbeans.api.keyring.Keyring) at org.netbeans.api.keyring.Keyring.access$100(Keyring.java:75) at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:128) at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:125) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443) at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68) at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058) "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.Dele
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:05 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#ff}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#ff}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock {color:#ff}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {code:java} "org.netbeans.api.keyring.Keyring" #26 daemon prio=1 os_prio=-2 tid=0x19593000 nid=0x1640 waiting for monitor entry [0x2655e000] java.lang.Thread.State: BLOCKED (on object monitor) at org.netbeans.ModuleManager$SystemClassLoader.getResourcesImpl(ModuleManager.java:708) - waiting to lock <0xc0d64370> (a org.netbeans.ModuleManager$SystemClassLoader) at org.netbeans.ProxyClassLoader.getResources(ProxyClassLoader.java:390) at org.openide.util.lookup.MetaInfServicesLookup.search(MetaInfServicesLookup.java:205) at org.openide.util.lookup.MetaInfServicesLookup.beforeLookup(MetaInfServicesLookup.java:156) at org.openide.util.lookup.MetaInfServicesLookup.beforeLookupResult(MetaInfServicesLookup.java:135) at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:483) at org.openide.util.lookup.ProxyLookup$R.initResults(ProxyLookup.java:390) at org.openide.util.lookup.ProxyLookup$R.myBeforeLookup(ProxyLookup.java:673) at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:553) at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:513) at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:509) at org.openide.util.Lookup.lookupAll(Lookup.java:312) at org.netbeans.api.keyring.Keyring.provider(Keyring.java:89) - locked <0xf0525f68> (a java.lang.Class for org.netbeans.api.keyring.Keyring) at org.netbeans.api.keyring.Keyring.readImpl(Keyring.java:105) - locked <0xf0525f68> (a java.lang.Class for org.netbeans.api.keyring.Keyring) at org.netbeans.api.keyring.Keyring.access$100(Keyring.java:75) at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:128) at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:125) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443) at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68) at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058) "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.Dele
[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=16449908#comment-16449908 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 2:05 PM: -- @Geertjan, no it did not happen before. Now, I don't know from when exactly it started, I mean which JDK/NB version combination. Actually it doesn't matter. Now it no longer works and the reason has been quite clearly identified: dead locking while querying the Keyring. If you look at the extract from my block IDE thread dump you will see that: 1) "Thread-8" takes the lock {color:#FF}0xc0d64370 {color}in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thraed "*org.netbeans.api.keyring.Keyring*" where it tries to get the lock on {color:#FF}0xc0d64370{color}. Boom deadlock... This blocks all threads on the ModuleManager$SystemClassLoader lock on {color:#FF}0xc0d64370 {color}for every other thread including the AWT Event one which leads to the HMI freeze. {code:java} "org.netbeans.api.keyring.Keyring" #26 daemon prio=1 os_prio=-2 tid=0x19593000 nid=0x1640 waiting for monitor entry [0x2655e000] java.lang.Thread.State: BLOCKED (on object monitor) at org.netbeans.ModuleManager$SystemClassLoader.getResourcesImpl(ModuleManager.java:708) - waiting to lock <0xc0d64370> (a org.netbeans.ModuleManager$SystemClassLoader) at org.netbeans.ProxyClassLoader.getResources(ProxyClassLoader.java:390) at org.openide.util.lookup.MetaInfServicesLookup.search(MetaInfServicesLookup.java:205) at org.openide.util.lookup.MetaInfServicesLookup.beforeLookup(MetaInfServicesLookup.java:156) at org.openide.util.lookup.MetaInfServicesLookup.beforeLookupResult(MetaInfServicesLookup.java:135) at org.openide.util.lookup.AbstractLookup.lookup(AbstractLookup.java:483) at org.openide.util.lookup.ProxyLookup$R.initResults(ProxyLookup.java:390) at org.openide.util.lookup.ProxyLookup$R.myBeforeLookup(ProxyLookup.java:673) at org.openide.util.lookup.ProxyLookup$R.computeResult(ProxyLookup.java:553) at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:513) at org.openide.util.lookup.ProxyLookup$R.allInstances(ProxyLookup.java:509) at org.openide.util.Lookup.lookupAll(Lookup.java:312) at org.netbeans.api.keyring.Keyring.provider(Keyring.java:89) - locked <0xf0525f68> (a java.lang.Class for org.netbeans.api.keyring.Keyring) at org.netbeans.api.keyring.Keyring.readImpl(Keyring.java:105) - locked <0xf0525f68> (a java.lang.Class for org.netbeans.api.keyring.Keyring) at org.netbeans.api.keyring.Keyring.access$100(Keyring.java:75) at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:128) at org.netbeans.api.keyring.Keyring$1.call(Keyring.java:125) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443) at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.java:68) at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2058) "Thread-8" #49 prio=6 os_prio=0 tid=0x256a5000 nid=0xdb8 waiting on condition [0x2cd7a000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0xf05d6c10> (a org.openide.util.RequestProcessor$RPFutureTask) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429) at java.util.concurrent.FutureTask.get(FutureTask.java:191) at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) at org.netbeans.core.ProxySettings.getAuthenticationPassword(ProxySettings.java:230) at org.netbeans.core.NbAuthenticator.getPasswordAuthentication(NbAuthenticator.java:87) at java.net.Authenticator.requestPasswordAuthentication(Authenticator.java:317) - locked <0xc2c66008> (a org.netbeans.core.NbAuthenticator) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.getAnswer(NegotiateCallbackHandler.java:65) at sun.net.www.protocol.http.spnego.NegotiateCallbackHandler.handle(NegotiateCallbackHandler.java:86) at com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:858) at com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:704) at com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:617) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.D
[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=16449647#comment-16449647 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 11:17 AM: --- I need to stress that this issue is super critical, because it occurs systematically and it makes NB IDE unusable. People will drop NB in favor for other (more reliable?) IDE's which is pity and not to speak about the NB platform applications... It is hard to defend and advertise the usage of NB in your company when it just blocks right after startup. It is event more difficult since you have a free community edition of IntelliJ. was (Author: jmborer): I need to stress that this issue is super critical, because it occurs systematically and it makes NB IDE unusable. People will drop NB in favor for other (more reliable?) IDE's which is pity and not to speak about the NB platform applications... It is hard to defend and advertise the usage of NB in your company when it just blocks right after startup... > 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 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, 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 Swi
[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=16449647#comment-16449647 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 11:11 AM: --- I need to stress that this issue is super critical, because it occurs systematically and it makes NB IDE unusable. People will drop NB in favor for other (more reliable?) IDE's which is pity and not to speak about the NB platform applications... It is hard to defend and advertise the usage of NB in your company when it just blocks right after startup... was (Author: jmborer): I need to stress that this issue is super critical, because it occurs systematically and it makes NB IDE unusable. People will drop NB in favor for other (more reliable?) IDE's which is pity and not to speak about the NB platform applications... It is hard to defend NB in your company when it just blocks right after startup... > 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 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, 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 Platf
[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=16449647#comment-16449647 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 11:10 AM: --- I need to stress that this issue is super critical, because it occurs systematically and it makes NB IDE unusable. People will drop NB in favor for other (more reliable) IDE's which is pity and not to speak about the NB platform applications... It is hard to defend NB in your company when it just blocks right after startup... was (Author: jmborer): I need to stress that this issue is super critical, because it occurs systematically it makes NB IDE unusable. People will drop NB in favor for other (more reliable) IDE's which is pity and not to speak about the NB platform applications... It is hard to defend NB in your company when it just blocks right after startup... > 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 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, 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, {{NbAuth
[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=16449647#comment-16449647 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/24/18 11:10 AM: --- I need to stress that this issue is super critical, because it occurs systematically and it makes NB IDE unusable. People will drop NB in favor for other (more reliable?) IDE's which is pity and not to speak about the NB platform applications... It is hard to defend NB in your company when it just blocks right after startup... was (Author: jmborer): I need to stress that this issue is super critical, because it occurs systematically and it makes NB IDE unusable. People will drop NB in favor for other (more reliable) IDE's which is pity and not to speak about the NB platform applications... It is hard to defend NB in your company when it just blocks right after startup... > 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 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, 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, {{N
[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=16449497#comment-16449497 ] Stephan Raible edited comment on NETBEANS-58 at 4/24/18 9:05 AM: - I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0_161 and _171 on a Windows 10 OS behind a corporate proxy as Jean-Marc Borrer mentioned. was (Author: mcrender): I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0._161 and _171 on a Windows 10 OS behind a corporate proxy as Jean-Marc Borrer mentioned. > 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 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, 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 > Authen
[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=16449497#comment-16449497 ] Stephan Raible edited comment on NETBEANS-58 at 4/24/18 9:05 AM: - I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0_161 and _171 on a Windows 10 OS behind a corporate proxy as Jean-Marc Borer mentioned. was (Author: mcrender): I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0_161 and _171 on a Windows 10 OS behind a corporate proxy as Jean-Marc Borrer mentioned. > 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 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, 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 > Authenti
[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=16449497#comment-16449497 ] Stephan Raible edited comment on NETBEANS-58 at 4/24/18 9:04 AM: - I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0._161 and _171 on a Windows 10 OS behind a corporate proxy as Jean-Marc Borrer mentioned. was (Author: mcrender): I can confirme the same behaviour of Netbeans 8.2 with JDK 1.8.0._161 and _171 on a Windows 10 OS behind a corporate proxy. > 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 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, 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
[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=16434018#comment-16434018 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/11/18 2:44 PM: -- I am not the man either for all this classloading stuff. :P was (Author: jmborer): I am not the man either for all this classloading fuss.:P > 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 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, 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 very likely to be needed when > application is still not "warm", i.e. during start
[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=16432425#comment-16432425 ] Geertjan Wielenga edited comment on NETBEANS-58 at 4/10/18 3:08 PM: Can you reproduce with earlier/later JDKs, with JDK 9, 10? Can you reproduce it with Apache NetBeans (i.e., instead of 8.2)? was (Author: geertjanwielenga): Can you reproduce with earlier/later JDKs, with JDK 9, 10? > 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 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, 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=16431984#comment-16431984 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/10/18 11:24 AM: --- My comment is a backport of this bugzilla entry which is still true and extremely annoying for me: https://netbeans.org/bugzilla/show_bug.cgi?id=262883 If I remember well, it appeared after upgrading to JDK 1.8 121, but not absolutely sure, since we often had trouble with the corporate proxy and I first thought it was my IT team that messed it up again and I had the network proxy disabled. My trouble started when I wanted to check for IDE updates and turned the proxy settings on again. was (Author: jmborer): My comment is a backport of this bugzilla entry which is still true and extremely annoying for me: https://netbeans.org/bugzilla/show_bug.cgi?id=262883 If I remember well, it appeared after upgrading to JDK 1.8 121, but not absolutely sure, since I we often had trouble with the corporate proxy and I first thought it was my IT team that messed it up again and I had the network proxy disabled. My trouble started when I wanted to check for IDE updates and turned the proxy settings on 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 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, 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!, ther
[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=16431958#comment-16431958 ] Jean-Marc Borer edited comment on NETBEANS-58 at 4/10/18 9:14 AM: -- We started running into this issue (Frozen stack trace with Java x64 8_162 and Netbeans 8.2 Win7x64) . No idea, why we never saw it before. Maybe someone changed something in the corporate proxy, but this is completely out of our reach. Once Netbeans is frozen, VisualVM can no longer properly interact with it. I managed to monitor NB with VisualVM before the freeze: thread view update. When NB freezes, thread view is also blocked, but I can still do a thread dump... VisualVM also suffers from this freezing bug as well as any NB platform application. No really astonishing since it based on NB platform. When we use "Manual Proxy Settings" from "No Proxy" it first works. Then we close the IDE and reopen it. It starts, but as soon as I try an action using the classloader such as opening a menu, it freezes completely. I managed to get a thread dump and the conclusion is similar to the ones here (I will attach it too). Unfortunately, https://bitbucket.org/phansson/netbeansproxy2 does not solve the issue at all. Same behaviour. After further analysis of my second thread [^nb-freeze-dump.txt] one can see that the issue lies in: 1) "Thread-8" takes the lock 0xc0d64370 in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thred "org.netbeans.api.keyring.Keyring" where it tries to get the lock on 0xc0d64370. Boom deadlock... This blocks the lock on 0xc0d64370 for every other thread including the AWT Event one. Workaround #1 doesn't work. The only solution currently is to work offline with "No proxy" or use a local proxy such as CNTLM, which then allows corporate proxy authentication and doesn't lead to this Keyring/Authenticator deadlock. [1] https://netbeans.org/bugzilla/show_bug.cgi?id=262883 [2] http://cntlm.sourceforge.net/ was (Author: jmborer): We started running into this issue (Frozen stack trace with Java x64 8_162 and Netbeans 8.2 Win7x64) . No idea, why we never saw it before. Maybe someone changed something in the corporate proxy, but this is completely out of our reach. Once Netbeans is frozen, VisualVM can no longer properly interact with it. I managed to monitor NB with VisualVM before the freeze: thread view update. When NB freezes, thread view is also blocked, but I can still do a thread dump... VisualVM also suffers from this freezing bug as well as any NB platform application. No really astonishing since it based on NB platform. When we use "Manual Proxy Settings" from "No Proxy" it first works. Then we close the IDE and reopen it. It starts, but as soon as I try an action using the classloader such as opening a menu, it freezes completely. I managed to get a thread dump and the conclusion is similar to the ones here (I will attach it too). Unfortunately, https://bitbucket.org/phansson/netbeansproxy2 does not solve the issue at all. Same behaviour. The only solution currently is to work offline with "No proxy" or use a local proxy such as CNTLM, which then allows corporate proxy authentication and doesn't lead to this Keyring/Authenticator deadlock. After further analysis of my second thread [^nb-freeze-dump.txt] one can see that the issue lies in: 1) "Thread-8" takes the lock 0xc0d64370 in sun.net.www.protocol.http.AuthenticationHeader.parse(AuthenticationHeader.java:200) Then further down the call stack, it creates a task that will wait forever reading the a value from Keyring at org.netbeans.api.keyring.Keyring.read(Keyring.java:144) 2) This task is posted on thred "org.netbeans.api.keyring.Keyring" where it tries to get the lock on 0xc0d64370. Boom deadlock... This blocks the lock on 0xc0d64370 for every other thread including the AWT Event one. [1] https://netbeans.org/bugzilla/show_bug.cgi?id=262883 [2] http://cntlm.sourceforge.net/ > 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 > Environment: Primarily Windows. >Reporter: phansson >Priority: Critical > Attachments: NETBEANS-58-workaround1.diff, nb-freeze-dump.txt, > netbeans.txt > > > When any network operation is performed, such as att