Bug 170182

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.