Class SmartExecutorUtils

java.lang.Object
org.eclipse.aether.util.concurrency.SmartExecutorUtils

public final class SmartExecutorUtils extends Object
Utilities for executors and sizing them. Big fat note: Do not use this class outside of resolver. This and related classes are not meant as "drop in replacement" for Jave Executors, is used in very controlled fashion only.
Since:
2.0.11
  • Method Details

    • newSmartExecutor

      public static SmartExecutor newSmartExecutor(Integer tasks, int maxConcurrentTasks, String namePrefix)
      Returns a smart executor for given parameters. If tasks is known (non-null), it must be greater than 0. The maxConcurrentTasks also must be greater than 0. The namePrefix must be non-null.

      If tasks is set (is known), and equals to 1 (one), or maxConcurrentTasks equals to 1, the DIRECT 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 return DIRECT 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 be null).
    • smartExecutor

      public static SmartExecutor smartExecutor(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, the maxConcurrentTask becomes global limit, and hence can be upped without unexpected "explosion" in increasing build threading or anything.