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.
Summary: | Adding J2EE server hangs AWT thread in PhpVisibilityQuery.isVisible | ||
---|---|---|---|
Product: | php | Reporter: | _ tboudreau <tboudreau> |
Component: | Project | Assignee: | Tomas Mysik <tmysik> |
Status: | RESOLVED DUPLICATE | ||
Severity: | blocker | CC: | pjiricka |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
thread dump
thread dump Patch to quickly test if there is definitely no project |
Description
_ tboudreau
2009-07-25 04:59:01 UTC
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 *** |