Class CacheStats
java.lang.Object
org.frontcache.cache.CacheStats
A cheap size-and-churn snapshot of a cache processor, for the metrics exporter.
Deliberately NOT
getCacheStatus(), which the management API already returns: that one is a
Map<String, String> built for human display, and reading it costs a fresh Lucene
DirectoryReader every time. Fine for an operator clicking a console page; wrong for a
Prometheus scrape arriving every few seconds forever. Everything here is read from state the process
already holds.
Unknown is a value
Every field can beUNKNOWN, and the exporter registers no series for one that is. A cache
processor with no on-disk tier does not have an "index size of 0" - it has no index, and a gauge
reading a flat zero would be a lie an alert could be built on.
Micrometer-free on purpose
The cache package does not depend on the metrics package. Export is optional and off by default; having the cache implementations register meters directly would put an optional dependency on the request path's most central class. So the cache side exposes plain numbers andorg.frontcache.metrics stays the only thing that knows what a meter is.-
Field Summary
FieldsModifier and TypeFieldDescriptionstatic final CacheStatsstatic final longThe processor does not track this number. -
Constructor Summary
ConstructorsConstructorDescriptionCacheStats(long l1Entries, long l1Evictions, long l2Entries, long l2DiskBytes) Kept for cache processors that do not track L1's byte size -CacheProcessoris a reflection-loaded extension point, so an implementation outside this repo still compiles and still reports honestly: not tracking a number is whatUNKNOWNis for, and unlike theFallbackResolvercase a default here cannot silently answer a question wrongly.CacheStats(long l1Entries, long l1Evictions, long l1ContentBytes, long l2Entries, long l2DiskBytes) -
Method Summary
Modifier and TypeMethodDescriptionlongBytes of response CONTENT held in the in-memory tier, orUNKNOWN.longEntries in the in-memory tier, orUNKNOWN.longEntries evicted from the in-memory tier since JVM start, orUNKNOWN.longBytes the on-disk tier occupies, orUNKNOWN.longDocuments in the on-disk tier, orUNKNOWN.booleanisTracked(long value) toString()
-
Field Details
-
UNKNOWN
public static final long UNKNOWNThe processor does not track this number. Distinct from zero.- See Also:
-
NOT_TRACKED
-
-
Constructor Details
-
CacheStats
public CacheStats(long l1Entries, long l1Evictions, long l2Entries, long l2DiskBytes) Kept for cache processors that do not track L1's byte size -CacheProcessoris a reflection-loaded extension point, so an implementation outside this repo still compiles and still reports honestly: not tracking a number is whatUNKNOWNis for, and unlike theFallbackResolvercase a default here cannot silently answer a question wrongly. -
CacheStats
public CacheStats(long l1Entries, long l1Evictions, long l1ContentBytes, long l2Entries, long l2DiskBytes)
-
-
Method Details
-
getL1Entries
public long getL1Entries()Entries in the in-memory tier, orUNKNOWN. -
getL1Evictions
public long getL1Evictions()Entries evicted from the in-memory tier since JVM start, orUNKNOWN. A monotonic total, not a rate: Prometheus derives the rate, and it is the rate that says whether L1 is too small for the working set. -
getL1ContentBytes
public long getL1ContentBytes()Bytes of response CONTENT held in the in-memory tier, orUNKNOWN. Not the tier's retained heap: header maps, key strings and per-object overhead are not in it. The distinction matters wherever this is shown next to a JVM heap figure. Maintained as the cache changes rather than measured on demand - seeL1ByteCounter. -
getL2Entries
public long getL2Entries()Documents in the on-disk tier, orUNKNOWN. -
getL2DiskBytes
public long getL2DiskBytes()Bytes the on-disk tier occupies, orUNKNOWN. Answers "will the cache volume fill up", which the entry count does not - entry sizes on a page cache vary by orders of magnitude. -
isTracked
public boolean isTracked(long value) -
toString
-