16419dad35
The J2SE NIO APIs require that FileChannel close the underlying file descriptor if a thread is interrupted while it is inside of a read or write operation on that channel. This is insane, because it means we cannot share the file descriptor between threads. If a thread is in the middle of the FileChannel variant of IO.readFully() and it receives an interrupt, the pack will be automatically closed on us. This causes the other threads trying to use that same FileChannel to receive IOExceptions, which leads to the pack getting marked as invalid. Once the pack is marked invalid, JGit loses access to its entire contents and starts to report MissingObjectExceptions. Because PackWriter must ensure that the chosen pack file stays available until the current object's data is fully copied to the output, JGit cannot simply reopen the pack when its automatically closed due to an interrupt being sent at the wrong time. The pack may have been deleted by a concurrent `git gc` process, and that open file descriptor might be the last reference to the inode on disk. Once its closed, the PackWriter loses access to that object representation, and it cannot complete sending the object the client. Fortunately, RandomAccessFile's readFully method does not have this problem. Interrupts during readFully() are ignored. However, it requires us to first seek to the offset we need to read, then issue the read call. This requires locking around the file descriptor to prevent concurrent threads from moving the pointer before the read. This reduces the concurrency level, as now only one window can be paged in at a time from each pack. However, the WindowCache should already be holding most of the pages required to handle the working set for a process, and its own internal locking was already limiting us on the number of concurrent loads possible. Provided that most concurrent accesses are getting hits in the WindowCache, or are for different repositories on the same server, we shouldn't see a major performance hit due to the more serialized loading. I would have preferred to use a pool of RandomAccessFiles for each pack, with threads borrowing an instance dedicated to that thread whenever they needed to page in a window. This would permit much higher levels of concurrency by using multiple file descriptors (and file pointers) for each pack. However the code became too complex to develop in any reasonable period of time, so I've chosen to retrofit the existing code with more serialization instead. Bug: 308945 Change-Id: I2e6e11c6e5a105e5aef68871b66200fd725134c9 Signed-off-by: Shawn O. Pearce <spearce@spearce.org> |
||
|---|---|---|
| org.eclipse.jgit | ||
| org.eclipse.jgit.console | ||
| org.eclipse.jgit.http.server | ||
| org.eclipse.jgit.http.test | ||
| org.eclipse.jgit.iplog | ||
| org.eclipse.jgit.junit | ||
| org.eclipse.jgit.packaging | ||
| org.eclipse.jgit.pgm | ||
| org.eclipse.jgit.test | ||
| org.eclipse.jgit.ui | ||
| tools | ||
| .eclipse_iplog | ||
| .gitattributes | ||
| LICENSE | ||
| README | ||
| SUBMITTING_PATCHES | ||
| pom.xml | ||
README
== Java GIT ==
This package is licensed under the BSD.
org.eclipse.jgit/
A pure Java library capable of being run standalone, with no
additional support libraries. Some JUnit tests are provided
to exercise the library. The library provides functions to
read and write a GIT formatted repository.
All portions of jgit are covered by the BSD. Absolutely no GPL,
LGPL or EPL contributions are accepted within this package.
org.eclipse.jgit.test/
Unit tests for org.eclipse.jgit and the same licensing rules.
== WARNINGS / CAVEATS ==
- Symbolic links are not supported because java does not support it.
Such links could be damaged.
- Only the timestamp of the index is used by jgit check if the index
is dirty.
- Don't try the library with a JDK other than 1.6 (Java 6) unless you
are prepared to investigate problems yourself. JDK 1.5.0_11 and later
Java 5 versions *may* work. Earlier versions do not. JDK 1.4 is *not*
supported. Apple's Java 1.5.0_07 is reported to work acceptably. We
have no information about other vendors. Please report your findings
if you try.
- CRLF conversion is never performed. On Windows you should thereforc
make sure your projects and workspaces are configured to save files
with Unix (LF) line endings.
== Package Features ==
org.eclipse.jgit/
* Read loose and packed commits, trees, blobs, including
deltafied objects.
* Read objects from shared repositories
* Write loose commits, trees, blobs.
* Write blobs from local files or Java InputStreams.
* Read blobs as Java InputStreams.
* Copy trees to local directory, or local directory to a tree.
* Lazily loads objects as necessary.
* Read and write .git/config files.
* Create a new repository.
* Read and write refs, including walking through symrefs.
* Read, update and write the Git index.
* Checkout in dirty working directory if trivial.
* Walk the history from a given set of commits looking for commits
introducing changes in files under a specified path.
* Object transport
Fetch via ssh, git, http, Amazon S3 and bundles.
Push via ssh, git and Amazon S3. JGit does not yet deltify
the pushed packs so they may be a lot larger than C Git packs.
org.eclipse.jgit.pgm/
* Assorted set of command line utilities. Mostly for ad-hoc testing of jgit
log, glog, fetch etc.
== Missing Features ==
There are a lot of missing features. You need the real Git for this.
For some operations it may just be the preferred solution also. There
are not just a command line, there is e.g. git-gui that makes committing
partial files simple.
- Merging.
- Repacking.
- Generate a GIT format patch.
- Apply a GIT format patch.
- Documentation. :-)
- gitattributes support
In particular CRLF conversion is not implemented. Files are treated
as byte sequences.
- submodule support
Submodules are not supported or even recognized.
== Support ==
Post question, comments or patches to the git@vger.kernel.org mailing list.
== Contributing ==
See SUBMITTING_PATCHES in this directory. However, feedback and bug reports
are also contributions.
== About GIT ==
More information about GIT, its repository format, and the canonical
C based implementation can be obtained from the GIT websites:
http://git.or.cz/
http://www.kernel.org/pub/software/scm/git/
http://www.kernel.org/pub/software/scm/git/docs/