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.
see attached thread dump. I've created a maven project, after that the world stopped turning.
Created attachment 86082 [details] deadlock
Beautiful, thanks!
This should fix the deadlock - http://hg.netbeans.org/jet-main/rev/2dbdd73232f0 Btw. org.netbeans.modules.maven.cos.CopyResourcesOnSave.fileChanged(CopyResourcesOnSave.java:159) could probably safely ignore any events coming from the system FileSystem as there can't be any maven projects installed on SFS. I did the same in RepositoryUpdater and it provided a considerable boost in performance, because FileOwnerQuery is generally slow and there seem to be quite a few filesystem events coming from SFS. Or maybe even our FileOwnerQuery implementation could ignore files coming from locations known not to contain projects such as SFS.
I don't see any code like that in parsing.api/src/org/netbeans/modules/parsing/impl/indexing/RepositoryUpdater.java ...?
Integrated into 'main-golden', will be available in build *200908140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/2dbdd73232f0 User: Vita Stejskal <vstejskal@netbeans.org> Log: #170182 - do not fire filesystem events when holding CacheFolder.class lock
RU.fileChanged calls RU.isCacheFile, which checks if the file from the event is from inside of <userdir>/var/cache/index, which we know will never contain projects. Maybe we could check more, eg. f.getFS() == SystemFS or similar. But for RU the biggest problem was huge amount of events generated by lucene when indexing.
Attaching a global listener via FileUtil.addFileChangeListener(FCL) and then discarding any events not coming from CacheFolder.getCacheFolder() seems quite inefficient to me. Maybe you meant to use FileUtil.addFileChangeListener(FCL,File)? Regarding FOQ, I will add an INFO stack trace if someone does ask whether a folder in SFS is a project. If we see some violations we can decide whether they need to be fixed. I did not notice anything just from running the IDE on some NBM projects.
Integrated into 'main-golden', will be available in build *200908150201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/292de8f2defa User: Jesse Glick <jglick@netbeans.org> Log: Noting any calls to FOQ for files on SFS. (Suggested in #170182.)
> Attaching a global listener via FileUtil.addFileChangeListener(FCL) and then discarding any events not coming from > CacheFolder.getCacheFolder() seems quite inefficient to me. Maybe you meant to use > FileUtil.addFileChangeListener(FCL,File)? Ideally, I would like to use FU.addFCL(FCL,File) for each source root that is scanned. But to my knowledge FU.addFCL does not listen recursively on the whole folders hierarchy under File. Adding FCL on each folder separately is possible, but probably unreliable unless we keep references to all folder FileObjects to make sure that we don't miss events. But this would IMO have very bad impact on memory usage. So, at the moment having one global FCL and filtering events seems like the only viable solution. Please advise if I am wrong.
Regarding file change listeners, you had best ask FS API developers, namely jskrivanek. To my knowledge there is still no satisfactory way of listening to changes in a directory tree.
Integrated into 'main-golden', will be available in build *200908210201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/fb9f155d776b User: Jesse Glick <jglick@netbeans.org> Log: #170443: removing check for SFS introduced due to suggestion in #170182; just added noise when creating new project.