Class SmartExecutorUtils
- Since:
- 2.0.11
-
Method Summary
Modifier and TypeMethodDescriptionstatic SmartExecutornewSmartExecutor(Integer tasks, int maxConcurrentTasks, String namePrefix) Returns a smart executor for given parameters.static SmartExecutorsmartExecutor(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. Iftasksis known (non-null), it must be greater than 0. ThemaxConcurrentTasksalso must be greater than 0. ThenamePrefixmust be non-null.If
tasksis set (is known), and equals to 1 (one), ormaxConcurrentTasksequals to 1, theDIRECTexecutor 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
tasksparameter is given should not be cached (like in a session) as they may returnDIRECTexecutor for one call and a pool for subsequent call, based on value of tasks.- Parameters:
tasks- the amount of tasks, if known,nullotherwisemaxConcurrentTasks- the maximum concurrency caller wantsnamePrefix- 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 maxConcurrentTaskper JVM/Maven process. Now, themaxConcurrentTaskbecomes global limit, and hence can be upped without unexpected "explosion" in increasing build threading or anything.
-