Class SmartExecutorUtils
- Since:
- 2.0.11
-
Method Summary
Modifier and TypeMethodDescriptionstatic SmartExecutor
newSmartExecutor
(Integer tasks, int maxConcurrentTasks, String namePrefix) Returns a smart executor for given parameters.static SmartExecutor
smartExecutor
(org.eclipse.aether.RepositorySystemSession session, Integer tasks, int maxConcurrentTasks, String namePrefix) Returns a smart executor, bound to session if tasks to execute are not known ahead of time.
-
Method Details
-
newSmartExecutor
public static SmartExecutor newSmartExecutor(Integer tasks, int maxConcurrentTasks, String namePrefix) Returns a smart executor for given parameters. Iftasks
is known (non-null), it must be greater than 0. ThemaxConcurrentTasks
also must be greater than 0. ThenamePrefix
must be non-null.If
tasks
is set (is known), and equals to 1 (one), ormaxConcurrentTasks
equals to 1, theDIRECT
executor is returned, otherwise pooled one.If @code tasks} is not set (is null), pooled one is returned with pool size of
maxConcurrentTasks
. In this case caller is advised to reuse created executor across session.The returned instance must be closed out, ideally in try-with-resources construct. Returned instances when
tasks
parameter is given should not be cached (like in a session) as they may returnDIRECT
executor for one call and a pool for subsequent call, based on value of tasks.- Parameters:
tasks
- The amount of tasks, if known,null
otherwise.maxConcurrentTasks
- The maximum concurrency caller wants.namePrefix
- The thread name prefixes, must not benull).
-
smartExecutor
public static SmartExecutor smartExecutor(org.eclipse.aether.RepositorySystemSession session, Integer tasks, int maxConcurrentTasks, String namePrefix) Returns a smart executor, bound to session if tasks to execute are not known ahead of time. The returned instance should be handled transparently, so preferably in try-with-resource even if underlying executor is probably tied to session lifecycle, if applicable.Implementation note: by this change, the caller "concurrency" is made deterministic and global(!). If you consider collector example, it is called from project builder that in Maven 4 is already multithreaded, and before this change the actual threads doing IO (HTTP) was
callerThreadCount x maxConcurrentTask
per JVM/Maven process. Now, themaxConcurrentTask
becomes global limit, and hence can be upped without unexpected "explosion" in increasing build threading or anything.
-