This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
NB 200810160201 What I did: 0) Install NB and enter a variable REPOSITORY in Tools->Variables pointing to some maven-style jar kitchen sink. 1) Create web project. 2) Reference library (in my case ojdbc14.jar) from project. 3) Rename project. NB hangs with progress bar stopping at 80%.
2) should have read 2) Reference library (in my case ojdbc14.jar) from project using REPOSITORY/ojdbc14.jar.
Created attachment 72132 [details] jstack -l dump while hanging.
Created attachment 72133 [details] Second jstack -l dump
After killing NB private.properties contains this line (among others): file.reference.ojdbc14.jar=C:\\home\\a0796942\\projects\\experimental\\WebApplication4\\${var.REPOSITORY}\\oracle-10.1\\jars\\ojdbc14.jar and the reference is broken.
Why refactoring component? EDT is blocked by web project rename. Reassigning.
> Why refactoring? On second thought it should have been obvious that renaming a project is fundamentally different from renaming packages, classes and so on. Next time I am not sure I'll choose IDE. But if the rename ran through would it leave the correct contents in project.properties? Cheers, Georg
Re. "deadlock" - this deadlock is not related to IDE variables. The deadlock is between Project.MUTEX and api.java.classpath.ClassPath. Tomas, first thing which seems to me dangerous is that ClassPath.createEntries() is calling SPI implementations while holding lock on instance of ClassPath. Is that necessary? Do you think that could be fixed? If not then possible *workaround* would be to use AWT.invokeLater in SourceRoots.resetCache(SourceRoots.java:468). RE. "wrong path in private.properties" - giorgio42, I would appreciate any steps how to reproduce.
Passing to Tomas for evaluation of ClassPath.createEntries().
RE. "wrong path in private.properties" - giorgio42, I would appreciate any steps how to reproduce. Perform the steps as described, close NB, reopen NB and the project, look at nbproject/private/project.properties. It will contain lines like these: file.reference.ojdbc14.jar=C:\\home\\a0796942\\projects\\experimental\\WebApplication4\\${var.REPOSITORY}\\oracle-10.1\\jars\\ojdbc14.jar instead of file.reference.ojdbc14.jar=${var.REPOSITORY}\\oracle-10.1\\jars\\ojdbc14.jar
Tomasi, please evaluate. Thanks
Deadlock among classpath lock and project mutex. To dkonecny: >first thing which seems to me dangerous is that ClassPath.createEntries() is calling SPI implementations while holding lock on instance of ClassPath Nice idea, however completely useless. The classpath does as much as it can not to call the SPI under the lock, it splits the critical sections, uses lamport clocks to prevent race conditions. If you look to the code you will find out that the PathResources were collected outside of the critical section. In the critical section only PR.getRoots() was called which resulted in simply returning the array of URLs, but it seems that ProxyFilteringCPI.getRoots tries to acquire project lock. On the other side, I can use your argument that project infrastructure calls SPI code (listeners) under lock.
So what are you suggesting to do? Re. "I can use your argument that project infrastructure calls SPI code (listeners) under lock" - true.
I will try to do a snapshot of roots where I'm doing the snapshots of PathResources (outside critical section). But I need to test it for a while if it doesn't introduce a race condition, probably a random test is the best for this.
Make sense. Thanks.
Fixed: http://hg.netbeans.org/main/rev/e7476997924e
Integrated into 'main-golden', will be available in build *200810280201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/e7476997924e User: Tomas Zezula <tzezula@netbeans.org> Log: #150555:Complete hang when renaming web project using variables
I cannot reproduce the problem in trunk -> verified
The fix was backported into release65_fixes repository. http://hg.netbeans.org/release65_fixes/rev/a7f1190c8886
verified in patch 1