Community
Participate
Working Groups
The window cache leaks file handles which leaves locked files on windows. This bug is discussed at http://mail-archives.apache.org/mod_mbox/maven-dev/201310.mbox/%3CCAJZRQKzQUt-usHvpf6-icbvhM5wMUecnwEvh0rMdbAhG1NDYCQ%40mail.gmail.com%3E It would appear the file descriptor that is being created at pack.beginWindowCache in WindowCache#load does not get freed in any deterministic manner. This stack trace shows YJP's idea of where the file handle was allocated, which also gives a fairly good testcase (org.eclipse.jgit.api.CloneCommand.call()) java.io.RandomAccessFile.<init>(File, String) org.eclipse.jgit.internal.storage.file.PackFile.doOpen() org.eclipse.jgit.internal.storage.file.PackFile.beginWindowCache() org.eclipse.jgit.internal.storage.file.WindowCache.load(PackFile, long) org.eclipse.jgit.internal.storage.file.WindowCache.getOrLoad(PackFile, long) org.eclipse.jgit.internal.storage.file.WindowCache.get(PackFile, long) org.eclipse.jgit.internal.storage.file.WindowCursor.pin(PackFile, long) org.eclipse.jgit.internal.storage.file.WindowCursor.copy(PackFile, long, byte[], int, int) org.eclipse.jgit.internal.storage.file.PackFile.readFully(long, byte[], int, int, WindowCursor) org.eclipse.jgit.internal.storage.file.PackFile.load(WindowCursor, long) org.eclipse.jgit.internal.storage.file.PackFile.get(WindowCursor, AnyObjectId) org.eclipse.jgit.internal.storage.file.ObjectDirectory.openObject1(WindowCursor, AnyObjectId) org.eclipse.jgit.internal.storage.file.FileObjectDatabase.openObjectImpl1(WindowCursor, AnyObjectId) org.eclipse.jgit.internal.storage.file.FileObjectDatabase.openObject(WindowCursor, AnyObjectId) org.eclipse.jgit.internal.storage.file.WindowCursor.open(AnyObjectId, int) org.eclipse.jgit.lib.ObjectReader.open(AnyObjectId) org.eclipse.jgit.revwalk.RevWalk.parseAny(AnyObjectId) org.eclipse.jgit.revwalk.RevWalk.parseCommit(AnyObjectId) org.eclipse.jgit.api.CloneCommand.parseCommit(Repository, Ref) org.eclipse.jgit.api.CloneCommand.checkout(Repository, FetchResult) org.eclipse.jgit.api.CloneCommand.call() org.apache.maven.scm.provider.git.jgit.command.checkout.JGitCheckOutCommand.executeCheckOutCommand(ScmProviderRepository,
Are you closing the repository after you're done cloning it ?
We use the porcelan API in most of the places and did not grap the underlying repo of the "Git" object to close it. Anyway, I just did now [1] - but it did not help, still the same issue on windows. I also had a look at the base class of the JGit testcase 'org.eclipse.jgit.api.CloneCommandTest' which is 'org.eclipse.jgit.junit.LocalDiskRepositoryTestCase' and this class seems to have quite some 'workarounds' to fix the same issues in the test cases - I guess I'll have to take a closer look at it. [1] https://github.com/imod/maven-scm/commit/598a90ea26cda92b6bbae4c8bf198d7176197d60
I suggest that we at least add a close() method to the Git class. User's of the JGit porcelain API should have the chance to close the repo without going too deep into low-level classes. See https://git.eclipse.org/r/#/c/18560
merged as 7dce16018e05c0a094b3eb20009e0438764f046e
This issue can be closed, I found the origin problem in our code: "Git.cloneRepository().call()" also returns an open repository, this was ignored and therefore also not closed. We now reuse this instance and everything seems to be fine after closing it. ...the addition of the new Git.close() method is a nice clean addition - will make use of it in the future.
closing as domi verified this works
