When attempting to find out what makes the javacvs module slow on checkouts,
I've discovered that the underlying reason is a problem in how the filesystem
locks files. Apparently, file-based file locking that is done by
o.n.m.masterfs.filebasedfs.fileobjects.WriteLock class is slow and
disk-intensive. This problem was apparently encountered before (issue #43278),
and solved by introducing a hack. A similar hack could work for javacvs, but
then there are also svn and other VCSs, copying directory trees from one place
to another, etc.
So, after reviewing the issue, my recommendation is to revise the whole locking
mechanism and decide, where file-based locking is unneeded and the "lightweight"
kind of locking could be used instead. Then provide API for outside parties to
do either kind of locking (currently the locks are always file-based, except
when you use the aforementioned hack).
It would also be interesting to find, why exactly file-based locking is so slow
right now. Could it be because it uses FileChannel acquired through
Too late for 6.0, risky. Should be reevaluated and finally reviewed
Here is a proposal to eliminate use of filebased locking:
I'd like this to be implemented for 6.1.
First draft implemented on branch with Tag: masterfs_novcs
Fixed by merging masterfs_novcs into trunk and by following commit fixing mainly #123542 Simplify MasterFS, do not
delegate on other embedded FS.