Class FcNodeStats
java.lang.Object
org.frontcache.core.FcNodeStats
A cheap snapshot of the JVM this node runs in: heap, process CPU, uptime.
The companion of
CacheStats - that one answers "what is in the cache",
this one answers "how is the process holding up" - and it follows the same two rules, for the same
reason. Everything is read from beans the JVM already maintains, because this is polled by a console
that never stops polling; and every field can be UNKNOWN, because a number this JVM cannot
produce has to be distinguishable from a real zero. A heap gauge flatlining at 0 is a lie somebody
eventually builds an alert on.
Micrometer-free on purpose
Micrometer ships JVM binders that produce all of this. It is deliberately not used here: metrics export is optional and off by default (front-cache.metrics.export=none), and the management
API has to answer whether or not anyone enabled it. Same reasoning as CacheStats, which
exposes plain numbers so that org.frontcache.metrics stays the only package that knows what
a meter is.
Nothing here throws
Every reader is guarded. This feeds an endpoint on a poll loop, and a management response that fails because one bean was unavailable is worse than one reportingUNKNOWN for that field.-
Field Summary
FieldsModifier and TypeFieldDescriptionstatic final FcNodeStatsstatic final longThe JVM does not report this number.static final doubleUNKNOWNfor the CPU load, which is a fraction rather than a count. -
Constructor Summary
ConstructorsConstructorDescriptionFcNodeStats(long heapUsedBytes, long heapMaxBytes, double cpuProcessLoad, long uptimeMillis) -
Method Summary
Modifier and TypeMethodDescriptionstatic FcNodeStatscurrent()Reads the JVM now.doubleRecent CPU used by THIS JVM as a fraction of all available cores (0..1), orUNKNOWN_LOAD.longThe heap ceiling, orUNKNOWN.longHeap currently in use, orUNKNOWN.longMilliseconds since JVM start, orUNKNOWN.booleanisTracked(double load) booleanisTracked(long value) toString()
-
Field Details
-
UNKNOWN
public static final long UNKNOWNThe JVM does not report this number. Distinct from zero.- See Also:
-
UNKNOWN_LOAD
public static final double UNKNOWN_LOADUNKNOWNfor the CPU load, which is a fraction rather than a count.- See Also:
-
NOT_TRACKED
-
-
Constructor Details
-
FcNodeStats
public FcNodeStats(long heapUsedBytes, long heapMaxBytes, double cpuProcessLoad, long uptimeMillis)
-
-
Method Details
-
getHeapUsedBytes
public long getHeapUsedBytes()Heap currently in use, orUNKNOWN. -
getHeapMaxBytes
public long getHeapMaxBytes()The heap ceiling, orUNKNOWN.MemoryUsage.getMax()already returns -1 when the maximum is undefined, which is the same valueUNKNOWNcarries - so an unbounded heap reports as untracked rather than as a ceiling of zero, and a caller rendering "used / max" has nothing to divide by. That is correct: there is no percentage to show. -
getCpuProcessLoad
public double getCpuProcessLoad()Recent CPU used by THIS JVM as a fraction of all available cores (0..1), orUNKNOWN_LOAD. Process CPU, not system CPU: on a shared host the system figure answers a question about the neighbours, not about this node. The HotSpot bean computes this over its own internal window and returns a negative value until it has two samples, so the first reading after a restart isUNKNOWN_LOAD. That is why the number is taken from the bean rather than from agetProcessCpuTime()delta kept here: a delta would be "since whoever last asked", which quietly means something different the moment a second console starts polling. -
getUptimeMillis
public long getUptimeMillis()Milliseconds since JVM start, orUNKNOWN. -
isTracked
public boolean isTracked(long value) -
isTracked
public boolean isTracked(double load) -
current
Reads the JVM now. Never throws, never blocks. -
toString
-