Class FcResilienceReload

java.lang.Object
org.frontcache.resilience.FcResilienceReload
public class FcResilienceReload extends Object
Applies an edited conf/resilience.properties to a running node, for the reload-resilience management action.

Why this needs a class of its own

The file is read once, into a volatile singleton, and then three caches are built from it and never revisited: FcResilienceConfig.getInstance(), the per-command-key Resilience4j objects in FcResilienceRegistry, and the per-pool-key executors in FcThreadPools. Re-reading the file alone changes nothing a request can observe, which is the trap this class exists to close - a "reload" that quietly applies none of the settings is worse than no reload at all.

What applies immediately, and what cannot

Command settings - timeouts, breaker thresholds, sleep windows, bulkhead permits, the COMMAND_KEY_INHERITANCE chain, the legacy hystrix.* prefixes - all come back through the normal path, because dropping the cached objects means the next command builds its config from scratch. Two things do not, and both are reported in FcResilienceReload.Result.warnings() rather than left to be inferred: dropping the cached breakers loses circuit state and the rolling windows the dashboard reads, and a changed maxQueueSize selects a queue TYPE that a running pool cannot be given (see FcThreadPools.reapplyGeometry(FcResilienceConfig)).