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: | MFS perf. enhancement => review of current impl. | ||
---|---|---|---|
Product: | platform | Reporter: | rmatous <rmatous> |
Component: | Filesystems | Assignee: | rmatous <rmatous> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | jtulach, pnejedly |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
rmatous
2002-02-14 09:08:14 UTC
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. |