Igniters! Here is a handsome moment in our current cache metrics API, that begs for an improvement and due to it significancy assumed to be discussed communitywise. Current CacheMetrics interface is confusing for a case, when it is accessed from a client node. One of the typical question is: *what CacheMetrics#getSize should return on a client Node for a non-Near non-Local cache?* Here are some options:
1. Zero. As it works now, it is just 0, since there is no entries on the client node. 2. Amount of all entries for this cache across the cluster. 3. Or, and here comes an interesting part, - amount of values which were fore.x. created through this client node, as it is useful for #getAveragePutTime. 4. .... Your variant? The same for the rest of the API: getCacheHits (0, cluster, client), getTxDhtCommitQueueSize (0, cluster, for client keys, UnsOpEx?). Assuming this point can give a good start for our discussion: there are use-cases, that demands metrics to be gathered for a client node separately, fore.x. user can measure latency between nodes, by comparing #getAveragePutTime on client and server side. Thus I consider reasonable to implement specific ClientCacheMetricsImpl with logic for client, but actual questions are: what should methods like getSize, getHits return? Is it necessary to support backward compatibility here for metrics API? Does the community think that it is reasonable to put our efforts to this task and that we want to support case for cache metrics on a client node? Thoughts?
