Use LinkedBlockingQueue for executor determining filesystem attributes

Using a fixed thread pool with unbounded LinkedBlockingQueue fixes the
RejectedExecutionException thrown if too many threads try to
concurrently determine filesystem attributes.

Comparing that to an alternative implementation using an unbounded
thread pool instead showed similar performance with the reproducer (in
range of 100-1000 threads in reproducer) on my mac:

threads   time

fixed threadpool up to 5 threads with LinkedBlockingQueue of unlimited
queue size
100       1103 ms
200       1602 ms
300       2369 ms
500       4002 ms
1000      11071 ms

unbounded cached threadpool
100       1108 ms
200       1591 ms
300       2299 ms
500       4577 ms
1000      11196 ms

Bug: 564202
Change-Id: I773da7414a1dca8e548349442dca9b56643be946
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

org.eclipse.jgit/src/org/eclipse/jgit/util/FS.java

@@ -52,7 +52,7 @@ import java.util.concurrent.ExecutionException;
 import java.util.concurrent.Executor;
 import java.util.concurrent.ExecutorService;
 import java.util.concurrent.Executors;
-import java.util.concurrent.SynchronousQueue;
+import java.util.concurrent.LinkedBlockingQueue;
 import java.util.concurrent.ThreadPoolExecutor;
 import java.util.concurrent.TimeUnit;
 import java.util.concurrent.TimeoutException;
@@ -235,7 +235,7 @@ public abstract class FS {
 		 * @see java.util.concurrent.Executors#newCachedThreadPool()
 		 */
 		private static final Executor FUTURE_RUNNER = new ThreadPoolExecutor(0,
-				5, 30L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>(),
+				5, 30L, TimeUnit.SECONDS, new LinkedBlockingQueue<Runnable>(),
 				runnable -> {
 					Thread t = new Thread(runnable, "FileStoreAttributeReader-" //$NON-NLS-1$
 							+ threadNumber.getAndIncrement());