summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.junit
diff options
context:
space:
mode:
authorDavid Turner <dturner@twosigma.com>2017-02-08 15:07:18 -0500
committerMatthias Sohn <matthias.sohn@sap.com>2017-06-06 01:18:29 +0200
commit6b1e3c58b16651dc72ec79a614d507e014d18393 (patch)
tree4e3d3fb306a70c46cc402a451a79c17e32181a70 /org.eclipse.jgit.junit
parentf17ec3928c45d7f5170e92b4e0e1f7390de5fff2 (diff)
downloadjgit-6b1e3c58b16651dc72ec79a614d507e014d18393.tar.gz
jgit-6b1e3c58b16651dc72ec79a614d507e014d18393.zip
Run auto GC in the background
When running an automatic GC on a FileRepository, when the caller passes a NullProgressMonitor, run the GC in a background thread. Use a thread pool of size 1 to limit the number of background threads spawned for background gc in the same application. In the next minor release we can make the thread pool configurable. In some cases, the auto GC limit is lower than the true number of unreachable loose objects, so auto GC will run after every (e.g) fetch operation. This leads to the appearance of poor fetch performance. Since these GCs will never make progress (until either the objects become referenced, or the two week timeout expires), blocking on them simply reduces throughput. In the event that an auto GC would make progress, it's still OK if it runs in the background. The progress will still happen. This matches the behavior of regular git. Git (and now jgit) uses the lock file for gc.log to prevent simultaneous runs of background gc. Further, it writes errors to gc.log, and won't run background gc if that file is present and recent. If gc.log is too old (according to the config gc.logexpiry), it will be ignored. Change-Id: I3870cadb4a0a6763feff252e6eaef99f4aa8d0df Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Diffstat (limited to 'org.eclipse.jgit.junit')
-rw-r--r--org.eclipse.jgit.junit/src/org/eclipse/jgit/junit/LocalDiskRepositoryTestCase.java7
1 files changed, 7 insertions, 0 deletions
diff --git a/org.eclipse.jgit.junit/src/org/eclipse/jgit/junit/LocalDiskRepositoryTestCase.java b/org.eclipse.jgit.junit/src/org/eclipse/jgit/junit/LocalDiskRepositoryTestCase.java
index 933faf9bfa..6ace9fc122 100644
--- a/org.eclipse.jgit.junit/src/org/eclipse/jgit/junit/LocalDiskRepositoryTestCase.java
+++ b/org.eclipse.jgit.junit/src/org/eclipse/jgit/junit/LocalDiskRepositoryTestCase.java
@@ -62,6 +62,7 @@ import java.util.TreeSet;
import org.eclipse.jgit.dircache.DirCache;
import org.eclipse.jgit.dircache.DirCacheEntry;
import org.eclipse.jgit.internal.storage.file.FileRepository;
+import org.eclipse.jgit.lib.ConfigConstants;
import org.eclipse.jgit.lib.Constants;
import org.eclipse.jgit.lib.ObjectId;
import org.eclipse.jgit.lib.PersonIdent;
@@ -121,6 +122,12 @@ public abstract class LocalDiskRepositoryTestCase {
mockSystemReader = new MockSystemReader();
mockSystemReader.userGitConfig = new FileBasedConfig(new File(tmp,
"usergitconfig"), FS.DETECTED);
+ // We have to set autoDetach to false for tests, because tests expect to be able
+ // to clean up by recursively removing the repository, and background GC might be
+ // in the middle of writing or deleting files, which would disrupt this.
+ mockSystemReader.userGitConfig.setBoolean(ConfigConstants.CONFIG_GC_SECTION,
+ null, ConfigConstants.CONFIG_KEY_AUTODETACH, false);
+ mockSystemReader.userGitConfig.save();
ceilTestDirectories(getCeilings());
SystemReader.setInstance(mockSystemReader);