[jira] [Commented] (NETBEANS-3744) NetBeans should load multi-project gradle projects in one shot
[
https://issues.apache.org/jira/browse/NETBEANS-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023703#comment-17023703
]
Laszlo Kishalmi commented on NETBEANS-3744:
---
Does git rebase updates the file's last modified timestamp?
BTW I'm sure that this can't be fixed for 11.3 I'm trying to add the new Gradle
Core stuff early 12.0, so you might try to eat some dogfood soon.
Try to add:--
{code:java}
-J-Dorg.netbeans.modules.gradle.GradleProjectCache.level=ALL
{code}
for more logging. It write some performance stuff to the IDE log, probably we
could look at it.
> NetBeans should load multi-project gradle projects in one shot
> --
>
> Key: NETBEANS-3744
> URL: https://issues.apache.org/jira/browse/NETBEANS-3744
> Project: NetBeans
> Issue Type: Bug
>Affects Versions: 11.1, 11.2
> Environment: Gradle 5.6 definitely exhibits this. Haven't tried 6.x
> yet.
> I think Gradle 4.10.3 did not have the issue, but we didn't have 100
> subprojects and/or use a shared build cache back then either.
>Reporter: Shevek
>Priority: Major
>
> It appears that NB does a gradle "build" (model, whatever) per subproject in
> a multi module project. Given a project with say 100 subprojects, two things
> happen:
> 1. It takes FOREVER, because 100 invocations of gradle takes FOREVER.
> 2. It never completes, because after 30 or 40 projects, Gradle runs out of
> RAM, and the Gradle JVM goes into GC Ergonomics while holding various
> system-wide Gradle locks, and now the entire system is hung and NO Gradle
> invocation on that system can proceed.
> Please can NetBeans load this project-set in one bite, with a single
> invocation, from which it can get all the model data (like it used to with
> the old Gradle plugin)?
> This is the major reason why NetBeans takes such a long time to load, and
> frequently, when it detects file changes, I can only get NB to be usable
> again by restarting it.
> I already gave Gradle 10Gb of RAM; the project is definitely buildable and
> testable in 2Gb, the rest is caches/leaks/whatever, that's Gradle's proble
> but it's vastly exacerbated by the NB Gradle model-loading strategy.
> Related: NETBEANS-3041 which at least gives me the 10Gb. Before that, I think
> NB just used to crash.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3744) NetBeans should load multi-project gradle projects in one shot
[ https://issues.apache.org/jira/browse/NETBEANS-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023694#comment-17023694 ] Shevek commented on NETBEANS-3744: -- rebase is triggering a reload even if no build metafiles change. > NetBeans should load multi-project gradle projects in one shot > -- > > Key: NETBEANS-3744 > URL: https://issues.apache.org/jira/browse/NETBEANS-3744 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.1, 11.2 > Environment: Gradle 5.6 definitely exhibits this. Haven't tried 6.x > yet. > I think Gradle 4.10.3 did not have the issue, but we didn't have 100 > subprojects and/or use a shared build cache back then either. >Reporter: Shevek >Priority: Major > > It appears that NB does a gradle "build" (model, whatever) per subproject in > a multi module project. Given a project with say 100 subprojects, two things > happen: > 1. It takes FOREVER, because 100 invocations of gradle takes FOREVER. > 2. It never completes, because after 30 or 40 projects, Gradle runs out of > RAM, and the Gradle JVM goes into GC Ergonomics while holding various > system-wide Gradle locks, and now the entire system is hung and NO Gradle > invocation on that system can proceed. > Please can NetBeans load this project-set in one bite, with a single > invocation, from which it can get all the model data (like it used to with > the old Gradle plugin)? > This is the major reason why NetBeans takes such a long time to load, and > frequently, when it detects file changes, I can only get NB to be usable > again by restarting it. > I already gave Gradle 10Gb of RAM; the project is definitely buildable and > testable in 2Gb, the rest is caches/leaks/whatever, that's Gradle's proble > but it's vastly exacerbated by the NB Gradle model-loading strategy. > Related: NETBEANS-3041 which at least gives me the 10Gb. Before that, I think > NB just used to crash. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-3744) NetBeans should load multi-project gradle projects in one shot
[ https://issues.apache.org/jira/browse/NETBEANS-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023692#comment-17023692 ] Shevek commented on NETBEANS-3744: -- I also haven't tracked if it's loading any projects multiple times. If you throw any performance logging into the gradle plugin/support, I'll gladly give feedback/results. > NetBeans should load multi-project gradle projects in one shot > -- > > Key: NETBEANS-3744 > URL: https://issues.apache.org/jira/browse/NETBEANS-3744 > Project: NetBeans > Issue Type: Bug >Affects Versions: 11.1, 11.2 > Environment: Gradle 5.6 definitely exhibits this. Haven't tried 6.x > yet. > I think Gradle 4.10.3 did not have the issue, but we didn't have 100 > subprojects and/or use a shared build cache back then either. >Reporter: Shevek >Priority: Major > > It appears that NB does a gradle "build" (model, whatever) per subproject in > a multi module project. Given a project with say 100 subprojects, two things > happen: > 1. It takes FOREVER, because 100 invocations of gradle takes FOREVER. > 2. It never completes, because after 30 or 40 projects, Gradle runs out of > RAM, and the Gradle JVM goes into GC Ergonomics while holding various > system-wide Gradle locks, and now the entire system is hung and NO Gradle > invocation on that system can proceed. > Please can NetBeans load this project-set in one bite, with a single > invocation, from which it can get all the model data (like it used to with > the old Gradle plugin)? > This is the major reason why NetBeans takes such a long time to load, and > frequently, when it detects file changes, I can only get NB to be usable > again by restarting it. > I already gave Gradle 10Gb of RAM; the project is definitely buildable and > testable in 2Gb, the rest is caches/leaks/whatever, that's Gradle's proble > but it's vastly exacerbated by the NB Gradle model-loading strategy. > Related: NETBEANS-3041 which at least gives me the 10Gb. Before that, I think > NB just used to crash. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-1921) Doesn't recognize single assignments on PHP Ternary Operator
[ https://issues.apache.org/jira/browse/NETBEANS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023688#comment-17023688 ] Junichi Yamamoto commented on NETBEANS-1921: Please also write the example code to reproduce it. > Doesn't recognize single assignments on PHP Ternary Operator > > > Key: NETBEANS-1921 > URL: https://issues.apache.org/jira/browse/NETBEANS-1921 > Project: NetBeans > Issue Type: Bug > Components: php - Editor >Affects Versions: 9.0 > Environment: Windows 7 Pro SP1 x64 >Reporter: Oscar F. Bustos Mora >Priority: Minor > Labels: starter > Attachments: asas.jpg > > > When doing ternary operator, NetBeans is assuming that in the line, a > variable is set twice instead setting it as result of an condition. > I know it's a visual annoyance and i kow how to disable this underlining but > maybe should inform about this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Updated] (NETBEANS-1921) Doesn't recognize single assignments on PHP Ternary Operator
[ https://issues.apache.org/jira/browse/NETBEANS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Junichi Yamamoto updated NETBEANS-1921: --- Component/s: (was: ide - Code) php - Editor > Doesn't recognize single assignments on PHP Ternary Operator > > > Key: NETBEANS-1921 > URL: https://issues.apache.org/jira/browse/NETBEANS-1921 > Project: NetBeans > Issue Type: Bug > Components: php - Editor >Affects Versions: 9.0 > Environment: Windows 7 Pro SP1 x64 >Reporter: Oscar F. Bustos Mora >Priority: Minor > Labels: starter > Attachments: asas.jpg > > > When doing ternary operator, NetBeans is assuming that in the line, a > variable is set twice instead setting it as result of an condition. > I know it's a visual annoyance and i kow how to disable this underlining but > maybe should inform about this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Assigned] (NETBEANS-1921) Doesn't recognize single assignments on PHP Ternary Operator
[ https://issues.apache.org/jira/browse/NETBEANS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xinrong Meng reassigned NETBEANS-1921: -- Assignee: (was: Xinrong Meng) > Doesn't recognize single assignments on PHP Ternary Operator > > > Key: NETBEANS-1921 > URL: https://issues.apache.org/jira/browse/NETBEANS-1921 > Project: NetBeans > Issue Type: Bug > Components: ide - Code >Affects Versions: 9.0 > Environment: Windows 7 Pro SP1 x64 >Reporter: Oscar F. Bustos Mora >Priority: Minor > Labels: starter > Attachments: asas.jpg > > > When doing ternary operator, NetBeans is assuming that in the line, a > variable is set twice instead setting it as result of an condition. > I know it's a visual annoyance and i kow how to disable this underlining but > maybe should inform about this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Assigned] (NETBEANS-1921) Doesn't recognize single assignments on PHP Ternary Operator
[ https://issues.apache.org/jira/browse/NETBEANS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xinrong Meng reassigned NETBEANS-1921: -- Assignee: Xinrong Meng > Doesn't recognize single assignments on PHP Ternary Operator > > > Key: NETBEANS-1921 > URL: https://issues.apache.org/jira/browse/NETBEANS-1921 > Project: NetBeans > Issue Type: Bug > Components: ide - Code >Affects Versions: 9.0 > Environment: Windows 7 Pro SP1 x64 >Reporter: Oscar F. Bustos Mora >Assignee: Xinrong Meng >Priority: Minor > Labels: starter > Attachments: asas.jpg > > > When doing ternary operator, NetBeans is assuming that in the line, a > variable is set twice instead setting it as result of an condition. > I know it's a visual annoyance and i kow how to disable this underlining but > maybe should inform about this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Comment Edited] (NETBEANS-106) NB classloaders should use fine grained locking
[ https://issues.apache.org/jira/browse/NETBEANS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023597#comment-17023597 ] Lars Bruun-Hansen edited comment on NETBEANS-106 at 1/25/20 3:59 PM: - Well, currently this is only "fixed" in JDK 14. The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as examplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important. I'll argue that it is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one. Therefore I still believe in this ticket. was (Author: lbruun): Well, currently this is only "fixed" in JDK 14. The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as examplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important. I'll argue that is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one. Therefore I still believe in this ticket. > NB classloaders should use fine grained locking > --- > > Key: NETBEANS-106 > URL: https://issues.apache.org/jira/browse/NETBEANS-106 > Project: NetBeans > Issue Type: Bug >Reporter: Lars Bruun-Hansen >Priority: Major > > In order to avoid issues such as NETBEANS-58 the NB classloaders should use > fine grained locking. (possibly only needed on System Classloader) > Background: At the time when the NB classloaders were created the general > consensus at the time was that a proper classloader used locking at the level > of the classloader itself. This was also how the classloaders in the JDK > worked. However, in Java 7 this > [changed|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html]. > The JDK classloaders started using more fine grained locking. But the NB > classloaders didn't follow suit. (it is not exactly an inheritable feature) > This means we are now in a situation were deadlocks occur in NB code which > cannot be reproduced with only the JDK. One such case is JDK-8068184 which > causes a severe freeze in NetBeans. We cannot expect the JDK folks to fix > problems that occur only in NB code. > What I propose is that a more fine grained locking mechanism is used. Look to > the JDK for inspiration. This will solve such deadlock issues. I don't think > it is necessary to actually claim that it is now fully multi-thread safe by > calling > [registerAsParallelCapable()|https://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable()]. > This can be left for a later exercise. First step is to remove the lock on > the classloader as a whole. > NETBEANS-58 contains a simple [minimal > example|https://issues.apache.org/jira/browse/NETBEANS-58?focusedCommentId=16224149=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16224149] > which can be used as a measure of success. Once an NB application can use > the pattern in the example without freezing then we have accomplished the > goal. > > (I'm personally not confident with fiddling with the NB classloaders. Scares > the sh.. out of me because I know it is the heart of the platform. So won't > come up with a PR. Sorry.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail:
[jira] [Comment Edited] (NETBEANS-106) NB classloaders should use fine grained locking
[ https://issues.apache.org/jira/browse/NETBEANS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023597#comment-17023597 ] Lars Bruun-Hansen edited comment on NETBEANS-106 at 1/25/20 3:58 PM: - Well, currently this is only "fixed" in JDK 14. The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as examplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important. I'll argue that is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one. Therefore I still believe in this ticket. was (Author: lbruun): Well, currently this is only "fixed" in JDK 14. The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as exemplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important. I'll argue that is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one. Therefore I still believe in this ticket. > NB classloaders should use fine grained locking > --- > > Key: NETBEANS-106 > URL: https://issues.apache.org/jira/browse/NETBEANS-106 > Project: NetBeans > Issue Type: Bug >Reporter: Lars Bruun-Hansen >Priority: Major > > In order to avoid issues such as NETBEANS-58 the NB classloaders should use > fine grained locking. (possibly only needed on System Classloader) > Background: At the time when the NB classloaders were created the general > consensus at the time was that a proper classloader used locking at the level > of the classloader itself. This was also how the classloaders in the JDK > worked. However, in Java 7 this > [changed|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html]. > The JDK classloaders started using more fine grained locking. But the NB > classloaders didn't follow suit. (it is not exactly an inheritable feature) > This means we are now in a situation were deadlocks occur in NB code which > cannot be reproduced with only the JDK. One such case is JDK-8068184 which > causes a severe freeze in NetBeans. We cannot expect the JDK folks to fix > problems that occur only in NB code. > What I propose is that a more fine grained locking mechanism is used. Look to > the JDK for inspiration. This will solve such deadlock issues. I don't think > it is necessary to actually claim that it is now fully multi-thread safe by > calling > [registerAsParallelCapable()|https://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable()]. > This can be left for a later exercise. First step is to remove the lock on > the classloader as a whole. > NETBEANS-58 contains a simple [minimal > example|https://issues.apache.org/jira/browse/NETBEANS-58?focusedCommentId=16224149=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16224149] > which can be used as a measure of success. Once an NB application can use > the pattern in the example without freezing then we have accomplished the > goal. > > (I'm personally not confident with fiddling with the NB classloaders. Scares > the sh.. out of me because I know it is the heart of the platform. So won't > come up with a PR. Sorry.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail:
[jira] [Commented] (NETBEANS-106) NB classloaders should use fine grained locking
[ https://issues.apache.org/jira/browse/NETBEANS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023597#comment-17023597 ] Lars Bruun-Hansen commented on NETBEANS-106: Well, currently this is only "fixed" in JDK 14. The fix in JDK-8068184 simply means that the JDK will no longer lock on the classloader. This lock was bad news for the NetBeans Platform because the Platform also puts a lock on the classloader. Hence a deadlock could easily occur as exemplified in NETBEANS-58. But it wasn't bad for anyone else i.e. those not using NetBeans Platforms but simply using JDK as-is. This is because the JDK's own class loaders (which aren't used in NetBeans Platform) do _not_ use a global lock on the class loader. This background is probably also the reason why the issue hasn't been addressed by the JDK developers for years, until now. It simply wasn't important. I'll argue that is only a matter of time before another JDK developer gets the idea to put a lock on the classloader, thinking that this is acceptable ...because it will actually work, except for those who also has the idea to put a lock on the classloader ... and they are not many, probably NB Platform is the only one. Therefore I still believe in this ticket. > NB classloaders should use fine grained locking > --- > > Key: NETBEANS-106 > URL: https://issues.apache.org/jira/browse/NETBEANS-106 > Project: NetBeans > Issue Type: Bug >Reporter: Lars Bruun-Hansen >Priority: Major > > In order to avoid issues such as NETBEANS-58 the NB classloaders should use > fine grained locking. (possibly only needed on System Classloader) > Background: At the time when the NB classloaders were created the general > consensus at the time was that a proper classloader used locking at the level > of the classloader itself. This was also how the classloaders in the JDK > worked. However, in Java 7 this > [changed|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html]. > The JDK classloaders started using more fine grained locking. But the NB > classloaders didn't follow suit. (it is not exactly an inheritable feature) > This means we are now in a situation were deadlocks occur in NB code which > cannot be reproduced with only the JDK. One such case is JDK-8068184 which > causes a severe freeze in NetBeans. We cannot expect the JDK folks to fix > problems that occur only in NB code. > What I propose is that a more fine grained locking mechanism is used. Look to > the JDK for inspiration. This will solve such deadlock issues. I don't think > it is necessary to actually claim that it is now fully multi-thread safe by > calling > [registerAsParallelCapable()|https://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable()]. > This can be left for a later exercise. First step is to remove the lock on > the classloader as a whole. > NETBEANS-58 contains a simple [minimal > example|https://issues.apache.org/jira/browse/NETBEANS-58?focusedCommentId=16224149=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16224149] > which can be used as a measure of success. Once an NB application can use > the pattern in the example without freezing then we have accomplished the > goal. > > (I'm personally not confident with fiddling with the NB classloaders. Scares > the sh.. out of me because I know it is the heart of the platform. So won't > come up with a PR. Sorry.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-106) NB classloaders should use fine grained locking
[ https://issues.apache.org/jira/browse/NETBEANS-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023525#comment-17023525 ] Benjamin Asbach commented on NETBEANS-106: -- [~jtulach], [~lbruun] The upstream issue seems to be fixed: [JDK-8068184|https://bugs.openjdk.java.net/browse/JDK-8068184] but I'm a little bit unsure what this means for this issue since there's some more activity on [NETBEANS-58|https://issues.apache.org/jira/browse/NETBEANS-58] but it. The test [~jlahoda] attached seems to be deleted during jira migration. > NB classloaders should use fine grained locking > --- > > Key: NETBEANS-106 > URL: https://issues.apache.org/jira/browse/NETBEANS-106 > Project: NetBeans > Issue Type: Bug >Reporter: Lars Bruun-Hansen >Priority: Major > > In order to avoid issues such as NETBEANS-58 the NB classloaders should use > fine grained locking. (possibly only needed on System Classloader) > Background: At the time when the NB classloaders were created the general > consensus at the time was that a proper classloader used locking at the level > of the classloader itself. This was also how the classloaders in the JDK > worked. However, in Java 7 this > [changed|https://docs.oracle.com/javase/7/docs/technotes/guides/lang/cl-mt.html]. > The JDK classloaders started using more fine grained locking. But the NB > classloaders didn't follow suit. (it is not exactly an inheritable feature) > This means we are now in a situation were deadlocks occur in NB code which > cannot be reproduced with only the JDK. One such case is JDK-8068184 which > causes a severe freeze in NetBeans. We cannot expect the JDK folks to fix > problems that occur only in NB code. > What I propose is that a more fine grained locking mechanism is used. Look to > the JDK for inspiration. This will solve such deadlock issues. I don't think > it is necessary to actually claim that it is now fully multi-thread safe by > calling > [registerAsParallelCapable()|https://docs.oracle.com/javase/7/docs/api/java/lang/ClassLoader.html#registerAsParallelCapable()]. > This can be left for a later exercise. First step is to remove the lock on > the classloader as a whole. > NETBEANS-58 contains a simple [minimal > example|https://issues.apache.org/jira/browse/NETBEANS-58?focusedCommentId=16224149=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16224149] > which can be used as a measure of success. Once an NB application can use > the pattern in the example without freezing then we have accomplished the > goal. > > (I'm personally not confident with fiddling with the NB classloaders. Scares > the sh.. out of me because I know it is the heart of the platform. So won't > come up with a PR. Sorry.) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org For additional commands, e-mail: commits-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
[jira] [Commented] (NETBEANS-58) NB IDE or NB Platform freeze on startup (proxy with Negotiate auth)
[
https://issues.apache.org/jira/browse/NETBEANS-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17023459#comment-17023459
]
Lars Bruun-Hansen commented on NETBEANS-58:
---
It is perhaps worth adding that in Java 13 the problem can possibly also be
avoided by setting {{sun.security.jgss.native=true}} on the JVM. See
[this|https://www.oracle.com/technetwork/java/13-relnote-issues-5460548.html#JDK-6722928].
I haven't tested it myself. This will mean that the Kerberos authentication
will now hopefully work on the workstation (seen from Java's perspective) and
there will therefore be no reason for the NetBeans Platform to present the
{{Authenticator}} and therefore the deadlock will not happen. This is the
theory, at least.
> 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
