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
>
