thomasmueller commented on code in PR #2607:
URL: https://github.com/apache/jackrabbit-oak/pull/2607#discussion_r2497798903
##########
oak-run/src/main/java/org/apache/jackrabbit/oak/run/Downloader.java:
##########
@@ -101,16 +107,21 @@ public Downloader(int concurrency, int connectTimeoutMs,
int readTimeoutMs, int
this.bufferSize = bufferSize;
this.executorService = new ThreadPoolExecutor(
- (int) Math.ceil(concurrency * .1), concurrency, 60L,
TimeUnit.SECONDS,
+ corePoolSize, concurrency, 60L, TimeUnit.SECONDS,
new LinkedBlockingQueue<>(),
BasicThreadFactory.builder().namingPattern("downloader-%d").daemon().build()
);
+ this.executorServiceForParts = new ThreadPoolExecutor(
+ corePoolSize, concurrency, 60L, TimeUnit.SECONDS,
+ new LinkedBlockingQueue<>(),
+
BasicThreadFactory.builder().namingPattern("partDownloader-%d").daemon().build()
+ );
Review Comment:
Well, because we use the default LinkedBlockingQueue(), in reality each of
the ThreadPoolExecutor will only create corePoolSize threads at most, and not
more. All other tasks are waiting in the queue.
(We could replace LinkedBlockingQueue with eg. SynchronousQueue, but then we
would get a RejectedExecutionException when we schedule more than max
concurrency tasks... So that wouldn't simplify things).
I wanted to keep the changes to the minimum, so I didn't try to fix other
things... So with 0.4 times concurrency corePoolSize, we have twice that number
of threads, so still below the limit.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
