ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ershov <vers...@gridgain.com>
Subject Client Cache metrics API design discussion.
Date Fri, 05 Feb 2016 16:44:05 GMT
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?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message