mirrors/jgit - jgit - source @ dussan.org

History

Antonio Barone 24d6d60538 Retry loose object read upon "Stale file handle" exception When reading loose objects over NFS it is possible that the OS syscall would fail with ESTALE errors: This happens when the open file descriptor no longer refers to a valid file. Notoriously it is possible to hit this scenario when git data is shared among multiple clients, for example by multiple gerrit instances in HA. If one of the two clients performs a GC operation that would cause the packing and then the pruning of loose objects, the other client might still hold a reference to those objects, which would cause an exception to bubble up the stack. The Linux NFS FAQ[1] (at point A.10), suggests that the proper way to handle such ESTALE scenarios is to: "[...] close the file or directory where the error occurred, and reopen it so the NFS client can resolve the pathname again and retrieve the new file handle." In case of a stale file handle exception, we now attempt to read the loose object again (up to 5 times), until we either succeed or encounter a FileNotFoundException, in which case the search can continue to Packfiles and alternates. The limit of 5 provides an arbitrary upper bounds that is consistent to the one chosen when handling stale file handles for packed-refs files (see [2] for context). [1] http://nfs.sourceforge.net/ [2] https://git.eclipse.org/r/c/jgit/jgit/+/54350 Bug: 573791 Change-Id: I9950002f772bbd8afeb9c6108391923be9d0ef51		2 years ago
..
gitrepo/internal	RepoText: Remove unused externalized string	4 years ago
internal	Retry loose object read upon "Stale file handle" exception	2 years ago
util/sha1	Move SHA1 compress/recompress files to resource folder	7 years ago