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.
When JarFS is created from jar on network drive, disk operations are of course somewhat slower. The problem is that auto-close time (300 ms) is often exceeded and during some actions (like scanning platform layers) jar files are needlessly closed and reopened. See attached snapshots, 1-st one shows scanning platform on NFS, and 2200 out of cca 2600 reOpenJarFile calls actually end up re-reading jar file, which on NFS sums up to 65% of the total scan time. 2-nd snapshot on regular local fs shows that 180 reOpeJarFile calls resulted in 42 actual file opens. Could there be an adaptive delay before closing the jar file instead of fixed one? E.g. when too many reopens within certain time are detected, it would double the auto-close time (up to some fixed limit of course). It would help a lot in such use-cases. There is a related issue that this scanning currently runs in AWT thread, it will be moved to background, but of course it won't give the results any faster.
Created attachment 83923 [details] Platform scan on network drive
Created attachment 83925 [details] Faster scan on local fs
I have a patch. The delay before closing of the jar file is adaptively adjusted between min (300 ms) and max (5000 ms) values according to actual period between two requests for reopening of the jar file. I will integrate it after vacation.
Created attachment 84822 [details] Patch.
Patch applied. core-main #82a11eb4fe97
Integrated into 'main-golden', will be available in build *200907290201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/82a11eb4fe97 User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #167527 - The delay before closing of the jar file is adaptively adjusted between min (300 ms) and max (5000 ms) values according to actual period between two requests for reopening of the jar file.