JMX metrics question

[javafanboy]

I have been debugging a quite complex Coherence application and run into that the JMX metrics (for instance totalGets) dont seem to be "exact" - i.e as soon as multiple threads are using a cache (I have looked at both near and local caches) fewer gets seems to be recorded than my application makes. Wen only one thread accesses the cache the metrics are correct.

Is this due to some a known feature / bug in Coherence or god forbid a problem with my program :-)

Attached is a small demo program (courtesy of AI code generator but reviewed and found to be reasonable) that tries to demonstrate this - specify one or more threads and see the ouptut...

For instance with two threads each making 50k get requests towards local cache it prints:

Units : 10000
HighUnits : 10000
LowUnits : 9000
Size : 10000
TotalGets : 98711
TotalPuts : 10000
CacheHits : 49825
CacheMisses : 48886
HitProbability: 0.5047563088206988
CachePrunes : 0

where about "TotalGets" was expected to be 100,000 but is 98711 ?!?!?

CoherenceLocalJmxHitsMissesDemo.java

[thegridman]

The code that updates those stats does not look at all thread safe or atomic to me. This was probably done on purpose for performance reasons to avoid needless locking.

[javafanboy]

Thanks for the confirmation of my suspicion Jonathan! Today counters can be done thread safe quite inexpensive (at least if not heavily contended) - it is quite annoying when debugging and the JMX stuff not line up with what you see in your own code :-( As cache updates are already thread safe (but perhaps on a partition level?) maybe some thread safe per patition counter could be sampled and aggregated to the JMX counters periodically - then at least the metrix would be eventually consistent rather than never consistent :-) At least some comments pointing out that the JMX counters are "approximative" would be nice if no plan of changing the implementation!

…

On Fri, Aug 29, 2025 at 3:52 PM Jonathan Knight ***@***.***> wrote: The code that updates those stats does not look at all thread safe or atomic to me. This was probably done on purpose for performance reasons to avoid needless locking. — Reply to this email directly, view it on GitHub <#145 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADXQF5T4BEBKQS7N2Z6QXD3QBLLJAVCNFSM6AAAAACFD4UWFGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMRVGYZTENI> . You are receiving this because you authored the thread.Message ID: ***@***.***>