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.
Using of atomic actions can lead to unexpected behaviour from point of view of client thtat listen on fileobjects. Also MultiFileObject that listen on delegates must call unnecessarily updateAll which leads to refresh of whole hierarchy. This behaviour is really inefficient and represent big performance problem (starup, en/dis able modules, switch of projects). Why can using of atomic actions lead to unexpected behaviour ? - because number of events fired from atomic action doesn`t need to correspond to number of events that would be fired without atomic action. This problem occures when hierarchy of FileObjects is created in atomic action (affects fileData/FolderCreated in MultiFileObject). Imagine that hierarchy Why ? - because events fired from atomic actions are basically fired at the rightplace to the queue and wait in the queue until atomic action is finished. But they are placed in the queue only if any listener is registered and listen on new created FileObject. MultiFileObject (or another listener) expects that is able track changes in hierarchy this way (imagine creation of B/C/D under A FileObject): 1. listen on A 2. catch event from A that B was created 3. listen on B 4. catch event from B that C was created 5. and so on But if /B/C/D is created in atomic action then: - from A is fired event that B was created and placed in queue (but not fired at the moment). So nobody knows about existence of B and then nobody can listen on B . Then B also doesn`t fire event that C was created because nobody listen on B and so on. Suggested solution: All events must be placed in queue regardless any listener is registered. List of listeners (that should be notified) must be created only at the moment when event should be fired to listenerers from queue.
But this means that one can receive event generated before the listener was registered. Strange is it not?
Should not the MFO be rewritten not to expect that it will not receive events until it asks for getChildren ()? As far as I know the LocalFS's FileObject will not fire any event (when a file is created using java.io.File) until somebody calls fileObject.getChildren (). So the MFO should receive an event on A and if interested (somebody asked for its children) call A.getChildren () which will immediatelly return B and there is no need to fire events to identify when B was created because for whole system the B was just discovered and we can assume that it existed for ever.
But this means that one can receive event generated before the listener was registered. Strange is it not? I don`t think it is strange. Listener receives event that was fired before the listener was registered. But your second comment is true and more painful because in other words mean that there is no possible to fully rely on fileevents. But then is unavoidable to check whole hierarchy of delegate that fired event to find all possible changes and compare it with current merge (in case that already method list () was called and cache of children exists). So we came close to the current solution that could be rewritten to be more lightweight. Then performance gain of this refactoring will be limited. That`s why priority was decreased and summary changed to: MFS perf. enhancement => review of current impl..
Improved handling of events in MultiFileObject. If fileDataCreated then is not necessary to call updateAll, because new created file cannot contain any hierarchy that must be followed in MFO. The same for fileDeleted if FileEvent.getFile ().isData (). Also updateAll used refresh for all MFObjects in hierarchy and for every MFO also delegates were refreshed, which is not necessary (so code was changed not to do it). So, now its much better.
I forgot to mark as fixed.
verified
Resolved for 3.4.x or earlier, no new info since then -> closing.