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.
Start NetBeans with a few Java projects open, but no web projects, and with no servers registered. In the Services window, add an instance of Tomcat 6. The UI is frozen for almost a minute (on a very fast machine). The attached thread dump shows the following at org.netbeans.modules.php.project.util.PhpProjectUtils.getPhpProject(PhpProjectUtils.java: 92) at org.netbeans.modules.php.project.PhpVisibilityQuery.isVisible(PhpVisibilityQuery.java:67) at org.netbeans.api.queries.VisibilityQuery.isVisible(VisibilityQuery.java:99) at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.fileChanged(RepositoryUpdate r.java:424) Not sure whether this is RepositoryUpdater being to aggressive, or if the code that creates the server instance is not using FileSystem.AtomicAction correctly, or why anything would be trying to find the project that owns an instance of a servlet container. Probably something is listening to the entire universe of fileobjects that should not be. Probably also the wizard should not create the new server instance in the AWT thread at all. But certainly PhpVisibilityQuery can and should do a less expensive test and fail quickly in such a case, without going through FileOwnerQuery.
Created attachment 85204 [details] thread dump
Also seems to cause an indefinite hang when creating a web project - this time, not in the AWT thread, but after creating the Tomcat instance, I tried to create a web project, and the UI has been hung at 25% of project creation finished for 10 minutes. Attaching two more thread dumps in a single file. Note that there are multiple threads inside PhpVisibilityQuery.isVisible(). Project creation finally completed after 12 minutes. One item of that may be of interest: The actual blockage seems to be in java.io.WinNTFileSystem.getBooleanAttributes(Native Method) which is a known bottleneck on Windows (much slower call than on Linux). I do have one drive mounted on Windows (using MS unix utilities) which is a remote NFS share. If for some reason it is trying to scan that (there are no files the IDE *should* know or care about there), that could be part of the problem. Either way, PhpVisibilityQuery.isVisible() can probably be optimized so that the negative test is much faster.
Created attachment 85205 [details] thread dump
Another note about the NFS share - it is currently mapped to an incorrect IP address, so it in fact is dead.
Created attachment 85209 [details] Patch to quickly test if there is definitely no project
Patch attached simply returns null quickly if an nbproject directory exists. Could be even more efficient if instead of "nbproject", some other name were used, or if a uniquely named marker file could be expected to be present in all php projects, so that the positive test does not have to go through FileOwnerQuery (but it is probably too late for this). fastCheckIsPossibleProject() takes ~0.25ms on my machine, and should solve the majority of the hangs. See related issue 169166 - there are two things that make this problem worse: - If you are running under $NBSRC/nbbuild/testuserdir, PhpVisibilityQuery.isVisible() is called every time there is a file change in any file in the system filesystem - It is called for many php files which are underneath $netbeans.home, where we can guarantee no project exists (issue 169166 is about that)
exists -> does not exist
Tim, thanks many times for the patch. Tomas, can you please evaluate? One thing to verify is the situation when project metadata are in a different directory than sources (see checkbox on the first panel of the New PHP Project wizard), and whether this patch could affect this. Thanks.
> One thing to verify is the situation when project metadata are in a different directory than sources I don't know how you'd ever detect this except by scanning the entire filesystem of the OS, unless there's some backreference in the sources (which probably means don't try) - although looking at open and recent projects is an option for a partial answer. However, we can at least guarantee that no project exists under $NB_INSTALL and skip that.
This issue will be fixed automatically by fixing issue #169038, or more precisely issue #169036.
Will be fixed by fixing issue #170308. *** This issue has been marked as a duplicate of 170308 ***