Class FcThreadPools

java.lang.Object
org.frontcache.resilience.FcThreadPools
public class FcThreadPools extends Object
The named thread pools Frontcache owns, replacing HystrixThreadPool. Resilience4j ships a ThreadPoolBulkhead and it is deliberately not used here. It requires queueCapacity >= 1, and Hystrix's maxQueueSize=-1 - what OriginPool runs with - means "no queue", i.e. a SynchronousQueue that rejects rather than buffers. That difference is not cosmetic: a queue in front of a slow origin converts fast rejection (and a fallback) into latency, which is the opposite of what the isolation is for. Owning a plain ThreadPoolExecutor also means the dashboard's thread-pool numbers can be read straight off it. See proposal section 5.2. Pools are node-level resources, not per-domain ones: all() returns every pool with no filtering, which is the fix for the thread-pool panel that has never rendered (section 6.6).

  • Method Details

    • pool

      public static ThreadPoolExecutor pool(String poolKey)

    • all

      public static Collection<String> all()
      Every pool, unfiltered. The dashboard's thread-pool frames are emitted from this to every authorized subscriber: a thread pool belongs to the node, so there is no per-domain answer to give - which is precisely why the old isOwnerGroup comparison (the POOL NAME against the caller's domain) could never be true and the panel was always empty.

    • existing

      public static ThreadPoolExecutor existing(String poolKey)

    • rejectionCount

      public static long rejectionCount(String poolKey)

    • reapplyGeometry

      public static List<String> reapplyGeometry(FcResilienceConfig config)
      Re-applies pool geometry to the live pools from a freshly read config, in place.

      Three of the four numbers are mutable; the fourth is not

      coreSize, maximumSize and keepAliveMinutes are settable on a running ThreadPoolExecutor. maxQueueSize is not: it selects the queue TYPE at construction - < 1 means a SynchronousQueue that rejects rather than buffers - and an executor's queue cannot be replaced. Recreating the pool would abandon or kill in-flight origin calls, so a changed maxQueueSize is reported and not applied. Silently ignoring it is how an operator concludes the setting does nothing.
      Returns:
      one human-readable warning per setting that could not be applied; empty when everything in the file is now live