neilcsmith-net commented on pull request #3136: URL: https://github.com/apache/netbeans/pull/3136#issuecomment-908339527
> I don't think there is a problem in org.openide.util.lookup package. Feel free to write a test to prove I am wrong. Neither do I. I think the problem is in `org.netbeans.modules.projectapi.LazyLookupProviders` and that [call to setLookups](https://github.com/apache/netbeans/blob/master/ide/projectapi/src/org/netbeans/modules/projectapi/LazyLookupProviders.java#L97) that is done holding the conditional lock. I'll have a think about a test for that scenario if you need one, but it's what the stack trace seems to suggest ? ... > Btw. I don't see any dump where lock are stuck in collectFires(). Please point me where you see something like that. I mean the thread with the lock from DelegatingLookupImpl is stuck in collectFires() rather than in calling through to its listeners. eg. all the stack traces show the following similar (trimmed) stack, with resultChanged() being called in DelegatingLookupImpl fired under the lock from one LazyLookupProviders proxy, taking the lock in DelegatingLookupImpl, then waiting on the lock in another LazyLookupProviders proxy during a call to collectFires(). ``` at org.netbeans.modules.projectapi.LazyLookupProviders$1Prov$1.beforeLookup(LazyLookupProviders.java:84) - waiting to re-lock in wait() <0x0000000601a8dca0> (a [Ljava.lang.Thread;) at org.openide.util.lookup.ProxyLookup.beforeLookup(ProxyLookup.java:268) ..... at org.openide.util.lookup.ProxyLookup$R.collectFires(ProxyLookup.java:645) at org.openide.util.lookup.ProxyLookup.setLookups(ProxyLookup.java:228) at org.openide.util.lookup.ProxyLookup.setLookups(ProxyLookup.java:184) at org.netbeans.spi.project.support.DelegatingLookupImpl.doDelegate(DelegatingLookupImpl.java:168) - locked <0x0000000601a8ef08> (a java.util.ArrayList) at org.netbeans.spi.project.support.DelegatingLookupImpl.resultChanged(DelegatingLookupImpl.java:84) at org.openide.util.lookup.ProxyLookup$1Notify.run(ProxyLookup.java:239) at org.openide.util.lookup.ProxyLookup.setLookups(ProxyLookup.java:248) at org.openide.util.lookup.ProxyLookup.setLookups(ProxyLookup.java:184) at org.netbeans.modules.projectapi.LazyLookupProviders$1Prov$1.beforeLookup(LazyLookupProviders.java:97) ``` Various of the other threads waiting on the lock in DelegatingLookupImpl are also being called under lock from a LazyLookupProvider proxy, presumably one of which is the one the above stack is waiting for. I'm not sure there's an easy way to ascertain which from a stack trace with this sort of conditional lock? I'd not even noticed it until I looked at your first commit here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
