1 /*
2 * Copyright (C) 2012, Roberto Tyley <roberto.tyley@gmail.com>
3 *
4 * This program and the accompanying materials are made available
5 * under the terms of the Eclipse Distribution License v1.0 which
6 * accompanies this distribution, is reproduced below, and is
7 * available at http://www.eclipse.org/org/documents/edl-v10.php
8 *
9 * All rights reserved.
10 *
11 * Redistribution and use in source and binary forms, with or
12 * without modification, are permitted provided that the following
13 * conditions are met:
14 *
15 * - Redistributions of source code must retain the above copyright
16 * notice, this list of conditions and the following disclaimer.
17 *
18 * - Redistributions in binary form must reproduce the above
19 * copyright notice, this list of conditions and the following
20 * disclaimer in the documentation and/or other materials provided
21 * with the distribution.
22 *
23 * - Neither the name of the Eclipse Foundation, Inc. nor the
24 * names of its contributors may be used to endorse or promote
25 * products derived from this software without specific prior
26 * written permission.
27 *
28 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
29 * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
30 * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
31 * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
32 * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
33 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
34 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
35 * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
36 * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
37 * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
38 * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
39 * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
40 * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
41 */
42
43 package org.eclipse.jgit.internal.storage.file;
44
45 import static org.junit.Assert.assertFalse;
46 import static org.junit.Assert.assertTrue;
47
48 import java.io.File;
49 import java.io.FilenameFilter;
50 import java.util.Collection;
51 import java.util.Collections;
52 import java.util.concurrent.Callable;
53 import java.util.concurrent.ExecutorService;
54 import java.util.concurrent.Executors;
55 import java.util.concurrent.Future;
56
57 import org.eclipse.jgit.junit.RepositoryTestCase;
58 import org.eclipse.jgit.lib.ConfigConstants;
59 import org.eclipse.jgit.lib.Constants;
60 import org.eclipse.jgit.lib.ObjectId;
61 import org.eclipse.jgit.revwalk.RevCommit;
62 import org.eclipse.jgit.storage.file.FileBasedConfig;
63 import org.junit.Assume;
64 import org.junit.Test;
65
66 public class ObjectDirectoryTest extends RepositoryTestCase {
67
68 @Test
69 public void testConcurrentInsertionOfBlobsToTheSameNewFanOutDirectory()
70 throws Exception {
71 ExecutorService e = Executors.newCachedThreadPool();
72 for (int i=0; i < 100; ++i) {
73 ObjectDirectory dir = createBareRepository().getObjectDatabase();
74 for (Future f : e.invokeAll(blobInsertersForTheSameFanOutDir(dir))) {
75 f.get();
76 }
77 }
78 }
79
80 /**
81 * Test packfile scanning while a gc is done from the outside (different
82 * process or different Repository instance). This situation occurs e.g. if
83 * a gerrit server is serving fetch requests while native git is doing a
84 * garbage collection. The test shows that when core.trustfolderstat==true
85 * jgit may miss to detect that a new packfile was created. This situation
86 * is persistent until a new full rescan of the pack directory is triggered.
87 *
88 * The test works with two Repository instances working on the same disk
89 * location. One (db) for all write operations (creating commits, doing gc)
90 * and another one (receivingDB) which just reads and which in the end shows
91 * the bug
92 *
93 * @throws Exception
94 */
95 @Test
96 public void testScanningForPackfiles() throws Exception {
97 ObjectId unknownID = ObjectId
98 .fromString("c0ffee09d0b63d694bf49bc1e6847473f42d4a8c");
99 GC gc = new GC(db);
100 gc.setExpireAgeMillis(0);
101 gc.setPackExpireAgeMillis(0);
102
103 // the default repo db is used to create the objects. The receivingDB
104 // repo is used to trigger gc's
105 try (FileRepository receivingDB = new FileRepository(
106 db.getDirectory())) {
107 // set trustfolderstat to true. If set to false the test always
108 // succeeds.
109 FileBasedConfig cfg = receivingDB.getConfig();
110 cfg.setBoolean(ConfigConstants.CONFIG_CORE_SECTION, null,
111 ConfigConstants.CONFIG_KEY_TRUSTFOLDERSTAT, true);
112 cfg.save();
113
114 // setup a repo which has at least one pack file and trigger
115 // scanning of the packs directory
116 ObjectId id = commitFile("file.txt", "test", "master").getId();
117 gc.gc();
118 assertFalse(receivingDB.hasObject(unknownID));
119 assertTrue(receivingDB.getObjectDatabase().hasPackedObject(id));
120
121 // preparations
122 File packsFolder = new File(receivingDB.getObjectsDirectory(),
123 "pack");
124 // prepare creation of a temporary file in the pack folder. This
125 // simulates that a native git gc is happening starting to write
126 // temporary files but has not yet finished
127 File tmpFile = new File(packsFolder, "1.tmp");
128 RevCommit id2 = commitFile("file.txt", "test2", "master");
129 // wait until filesystem timer ticks. This raises probability that
130 // the next statements are executed in the same tick as the
131 // filesystem timer
132 fsTick(null);
133
134 // create a Temp file in the packs folder and trigger a rescan of
135 // the packs folder. This lets receivingDB think it has scanned the
136 // packs folder at the current fs timestamp t1. The following gc
137 // will create new files which have the same timestamp t1 but this
138 // will not update the mtime of the packs folder. Because of that
139 // JGit will not rescan the packs folder later on and fails to see
140 // the pack file created during gc.
141 assertTrue(tmpFile.createNewFile());
142 assertFalse(receivingDB.hasObject(unknownID));
143
144 // trigger a gc. This will create packfiles which have likely the
145 // same mtime than the packfolder
146 gc.gc();
147
148 // To deal with racy-git situations JGit's Filesnapshot class will
149 // report a file/folder potentially dirty if
150 // cachedLastReadTime-cachedLastModificationTime < 2500ms. This
151 // causes JGit to always rescan a file after modification. But:
152 // this was true only if the difference between current system time
153 // and cachedLastModification time was less than 2500ms. If the
154 // modification is more than 2500ms ago we may have reported a
155 // file/folder to be clean although it has not been rescanned. A
156 // Bug. To show the bug we sleep for more than 2500ms
157 Thread.sleep(2600);
158
159 File[] ret = packsFolder.listFiles(new FilenameFilter() {
160 @Override
161 public boolean accept(File dir, String name) {
162 return name.endsWith(".pack");
163 }
164 });
165 assertTrue(ret.length == 1);
166 Assume.assumeTrue(tmpFile.lastModified() == ret[0].lastModified());
167
168 // all objects are in a new packfile but we will not detect it
169 assertFalse(receivingDB.hasObject(unknownID));
170 assertTrue(receivingDB.hasObject(id2));
171 }
172 }
173
174 private Collection<Callable<ObjectId>> blobInsertersForTheSameFanOutDir(
175 final ObjectDirectory dir) {
176 Callable<ObjectId> callable = new Callable<ObjectId>() {
177 public ObjectId call() throws Exception {
178 return dir.newInserter().insert(Constants.OBJ_BLOB, new byte[0]);
179 }
180 };
181 return Collections.nCopies(4, callable);
182 }
183
184 }