ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Menshikov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-6565) Use long type for size and keySize in cache metrics
Date Fri, 01 Dec 2017 11:23:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-6565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247735#comment-16247735
] 

Alexander Menshikov edited comment on IGNITE-6565 at 12/1/17 11:22 AM:
-----------------------------------------------------------------------

I have taken a look at the task, and want to ask some questions:

1) How better cast long to int?

Now in GridDhtCacheAdapter used simple casting "(int)size". But such code can return confusing
values. For example (int)(2*(Integer.MAX_VALUE+1L)+10L) == 10.

I think the best option to return Integer.MAX_VALUE at overflow. In such case, old client
applications will get the closest value to the right answer. New clients anyway have to use
long version.

2) getSize() vs getKeySize()

CacheMetrics#getSize() should return number of non-null values, but CacheMetrics#getKeySize()
return number of all entrys (because key can't be null). Javadoc say so. But CacheMetricsImpl#getKeySize()
just calls CacheMetricsImpl#getSize(). It happens because values can't be null too in IgniteCache.
By the way, CacheMetricsImpl#getSize() calls cache#size() and there isn't any cache.keySize()
like methods. So we probably can add Deprecated annotation to getKeySize() method and remove
it in some future release. Of course, only if we fully confident nullable values can't come
back.


was (Author: sharpler):
I have taken a look at the task, and want to ask some questions:

1) How better cast long to int?

Now in GridDhtCacheAdapter used simple casting "(int)size". But such code can return confusing
values. For example (int)(2*(Integer.MAX_VALUE+1L)+10L) == 10.

I think the best option to return Integer.MAX_VALUE at overflow. In such case, old client
applications will get the closest value to the right answer. New clients anyway have to use
long version.

2) getSize() vs getKeySize()

As I said in previous comment getSize() return number of non-null values, but getKeySize()
return number of all entrys (because key can't be null). Javadoc say so. But CacheMetricsImpl#getKeySize()
just calls CacheMetricsImpl#getSize(). Looks like a bug.

By the way, CacheMetricsImpl#getSize() calls cache#size() and there isn't any cache.keySize()
like methods.

> Use long type for size and keySize in cache metrics
> ---------------------------------------------------
>
>                 Key: IGNITE-6565
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6565
>             Project: Ignite
>          Issue Type: Improvement
>    Affects Versions: 2.2
>            Reporter: Ilya Kasnacheev
>            Assignee: Alexander Menshikov
>
> Currently it's int so for large caches there's no way to convey correct value.
> Should introduce getSizeLong() and getKeySizeLong()
> Also introduce the same in .Net and make sure that compatibility not broken when passing
OP_LOCAL_METRICS and OP_GLOBAL_METRICS.
> BTW do we need keySize at all? What's it for?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message