Hi Alex, Thank you for referring spec. It really gives strict point how JCache metrics should be counted. So, I will start implementation of metrics for MVCC caches according to spec and existing behavior.
As for improper "removals" calculation, I filed a ticket https://issues.apache.org/jira/browse/IGNITE-9300 2018-08-10 17:48 GMT+03:00 Alex Plehanov <plehanov.a...@gmail.com>: > Hi, Ivan > > Looks like a bug. Metrics counting described at JSR107 (JCache) > specification. It says, that "cache removals" metric should be incremented > if remove() method returns true. Since there are no matching keys in the > first remove() call should be found, remove() should return false and > "cache removals" metric should not be affected. > > 2018-08-10 12:56 GMT+03:00 Павлухин Иван <vololo...@gmail.com>: > > > Hi, > > > > Dmitriy thanks for note, I will keep metrics IEP in mind. > > > > Roman it sounds quite a straightforward approach. Moreover current cache > > transactions follow it: there could be a number of invisible actions in > > private workspace (e.g. creating and then deleting the same entry) but > only > > final changes are metered. > > > > Also, I observed strange behavior for TRANSACTIONAL cache operations. For > > following case metrics surprised me (numbers in comments): > > > > public void testPutRemove() throws Exception { > > cache.remove(1); > > System.out.println(cache.metrics().getCacheRemovals()); // 1 > > > > cache.put(1, "a"); > > > > cache.remove(1); > > System.out.println(cache.metrics().getCacheRemovals()); // 2 > > } > > > > While for ATOMIC cache I see 0 and 1 which looks much better. And similar > > effect is observed for "replace" operations. > > > > Is it a bug? Do we have some document describing how metrics should be > > counted? > > > > 2018-08-08 21:11 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > > > I think we should be updating the IEP with metrics specifications in > > > parallel. > > > > > > D. > > > > > > On Wed, Aug 8, 2018, 05:32 Roman Kondakov <kondako...@mail.ru.invalid> > > > wrote: > > > > > > > Hi Ivan! > > > > > > > > In my opinion we need to preserve the essence of the metrics: if we > > > > didn't consider dirty writes as updates before MVCC implementation, > we > > > > also shouldn't count these writes in MVCC metrics implementation too. > > > > So, I think we need to count only committed entries. But we can count > > > > this dirty writes as additional metrics. > > > > > > > > Also additional metrics concerning MVCC could be: > > > > > > > > - Average count of the active transactions per snapshot > > > > > > > > - Average quantity of versions per key > > > > > > > > > > > > -- > > > > > > > > Roman Kondakov > > > > > > > > > > > > On 07.08.2018 17:17, Павлухин Иван wrote: > > > > > Hi Igniters, > > > > > > > > > > I am working on cache metrics support for caches with enabled MVCC. > > As > > > > you > > > > > may know, during MVCC transaction execution entry versions are > > written > > > to > > > > > storage right away (without deferring until commit). So, it is not > > > > obvious > > > > > for me if we should update writes count right away or defer it > until > > > > > commit. On one hand, MVCC entry version write is not "true" write > > until > > > > > commit. On the other hand, it definitely changes the storage. How > do > > we > > > > > interpret write metrics in Ignite philosophy? > > > > > > > > > > Also, it seems that bunch of MVCC specific metrics could be > > > introduced. I > > > > > would like to collect some thoughts about it. Which such metrics > come > > > to > > > > > your mind? > > > > > > > > > > > > > > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > > -- Best regards, Ivan Pavlukhin
