Class FcCommandKeys

java.lang.Object
org.frontcache.resilience.FcCommandKeys
public class FcCommandKeys extends Object
The command keys, in one place. A command key is not an internal name. It owns a circuit breaker, a bulkhead and a time limiter; it is the <key> in resilience.command.<key>.*; it is the name field of a dashboard frame; and it is the command label on every frontcache_* metric series. They were string literals scattered across the FC_* classes until 2.9.0 renamed four of them and found them by grep.

What each one covers

  • Input-Request - a request from a client. The dashboard's headline traffic figure.
  • Include-Request - an include arriving back through this node's own front door.
  • Warm-Request - the cache warmer's own request, sent to this node's front door. Reads zero except during a warm run, which is the point: warm traffic stays off the headline number and off Input-Request's bulkhead.
  • Cache-Hit - a cache lookup. Every lookup, hit or miss, hence the surrounding command.
  • Cache-Miss - the origin call a cache miss makes.
  • Cache-Bypass - the origin call a request that never consults the cache makes.

Cache-Miss is two pre-2.9.0 keys combined

Cache-Origin-http (a socket to the origin) and Cache-Origin-filter (the filter chain of the app Frontcache is installed in) named the TRANSPORT, which is a property of how the node is deployed rather than of what the command does - both are "the origin call behind a cache miss", and an operator tuning one always wanted the same number in the other. They now share one key, and therefore one breaker, one bulkhead and one row on the dashboard. That is a behaviour change on a filter-mode node, and only there. A standalone node only ever used the http one. A filter-mode node uses the filter chain for the page's own origin call and HTTP for include fetches (fetchOverHttp is always HTTP, never the chain), so it had two independent breakers over the same origin and now has one. Sharing is the more correct answer - it is one origin, and a breaker that sees all of its failures opens on evidence the split version threw away - but the concurrency permits are now shared too.

The old names still configure the new ones

LEGACY_COMMAND_KEYS maps each new key to the pre-2.9.0 key it inherits settings from when a resilience.properties says nothing about the new name. Renaming a command key without this would silently reset that command to the built-in defaults - timeout=1000, maxConcurrentRequests=10 - on every node whose file predates the rename. For an origin call tuned to 10 or 20 seconds, that is not a metrics change, it is an outage. See FcResilienceConfig, which walks the chain.

  • Field Details

    • INPUT_REQUEST

      public static final String INPUT_REQUEST
      A request from a client - what an operator reads as "how much traffic is this node taking".
      See Also:

    • INCLUDE_REQUEST

      public static final String INCLUDE_REQUEST
      A Frontcache include arriving back through this node's own front door.
      See Also:

    • WARM_REQUEST

      public static final String WARM_REQUEST
      The cache warmer's loopback request - see org.frontcache.warmer.WarmRequest. Not a rename, so it has no LEGACY_COMMAND_KEYS entry. It inherits Input-Request's settings instead (FcResilienceConfig), which is what a warm request would have run under before the key existed - without that an un-edited resilience.properties would give it the built-in timeout=1000, and every page slower than a second would fail to warm.
      See Also:

    • CACHE_HIT

      public static final String CACHE_HIT
      A cache lookup - every lookup, whether it hits or misses.
      See Also:

    • CACHE_MISS

      public static final String CACHE_MISS
      The origin call behind a cache miss, whichever transport reaches the origin.
      See Also:

    • CACHE_BYPASS

      public static final String CACHE_BYPASS
      The origin call for a request that bypasses the cache entirely.
      See Also:

    • ORIGIN_POOL

      public static final String ORIGIN_POOL
      The thread pool every THREAD-isolated origin call runs on - CACHE_MISS and CACHE_BYPASS both. Named after what the pool is for rather than after either of the commands that use it: "calls to the origin" is the property those two share, and it is what an operator is sizing when they set coreSize. Called OriginHitsPool through 2.8, after the command key that became Cache-Bypass - which was the RARER of the two paths, so the old name pointed at the one that does not fill the pool.
      See Also:

    • LEGACY_COMMAND_KEYS

      public static final Map<String,String> LEGACY_COMMAND_KEYS
      New key -> the pre-2.9.0 key whose settings it falls back on. A LinkedHashMap because the order is the order these are reported in, and a stable order makes the startup line and any test over it deterministic. Cache-Miss inherits from Cache-Origin-http rather than Cache-Origin-filter because the http one is the key every deployment mode used - a filter-mode node fetches its includes over HTTP. A node that deliberately tuned the two differently is the one case this cannot carry over, and it has to set resilience.command.Cache-Miss.* explicitly. Cache-Hit is the one entry here that is only a spelling change: it was Cache-Hits before 2.9.0, and it was the last key left in the plural once the other renames put the rest in the singular. Nothing about the command moved - it is still every cache lookup - but the key is a config contract all the same, so an un-edited file keeps configuring it through the old name.

    • LEGACY_THREAD_POOL_KEYS

      public static final Map<String,String> LEGACY_THREAD_POOL_KEYS
      New thread-pool key -> the pre-2.9.0 key whose settings it falls back on. The same reasoning as LEGACY_COMMAND_KEYS, and if anything a sharper failure. A pool key that resolves to nothing does not stop at a merely different number: coreSize falls to threadpool.default.coreSize, and on a file that never set one, to the built-in 10. A node whose operator had tuned OriginHitsPool.coreSize=200 would come up capping every origin call at ten threads, having changed nothing.