Agree. All metrics should return the data for the whole cache, unless specifically specified otherwise by user.
D. On Fri, Feb 5, 2016 at 10:56 AM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Vladimir, > > As I already suggested in the ticket [1], I think that by default we should > return metrics for the whole cluster. Now we collect them only from local > node, which is confusing, especially on the client. If one needs metrics > for one node or from subset of nodes, metrics(ClusterGroup) method can be > used. > > So as for the size, I'm definitely for option 2. > > Option 3 is more about 'getCachePuts()', but not 'getSIze()', no? Where do > we increment this counter - on the client or on the primary node? If on the > client, this metric will work just as you described when you get metrics > for a particular client using metrics(ClusterGroup). > > Probably it also would be useful to add localMetrics() shortcut method. > > [1] https://issues.apache.org/jira/browse/IGNITE-2483 > > -Val > > On Fri, Feb 5, 2016 at 8:44 AM, Vladimir Ershov <vers...@gridgain.com> > wrote: > > > 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? > > >
