<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 5:03 PM, Mircea Markus <span dir="ltr"><<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Oct 3, 2014, at 9:30, Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> recently we had a discussion about what size() returns, but I've<br>
> realized there are more things that users would like to know. My<br>
> question is whether you think that they would really appreciate it, or<br>
> whether it's just my QA point of view where I sometimes compute the<br>
> 'checksums' of cache to see if I didn't lost anything.<br>
><br>
> There are those sizes:<br>
> A) number of owned entries<br>
> B) number of entries stored locally in memory<br>
> C) number of entries stored in each local cache store<br>
> D) number of entries stored in each shared cache store<br>
> E) total number of entries in cache<br>
><br>
> So far, we can get<br>
> B via withFlags(SKIP_CACHE_LOAD).size()<br>
> (passivation ? B : 0) + firstNonZero(C, D) via size()<br>
> E via distributed iterators / MR<br>
> A via data container iteration + distribution manager query, but only<br>
> without cache store<br>
> C or D through<br>
> getComponentRegistry().getLocalComponent(PersistenceManager.class).getStores()<br>
><br>
> I think that it would go along with users' expectations if size()<br>
> returned E and for the rest we should have special methods on<br>
> AdvancedCache. That would of course change the meaning of size(), but<br>
> I'd say that finally to something that has firm meaning.<br>
><br>
> WDYT?<br>
<br>
</div></div>There was a lot of arguments in past whether size() and other methods that operate over all the elements (keySet, values) are useful because:<br>
- they are approximate (data changes during iteration)<br>
- they are very resource consuming and might be miss-used (this is the reason we chosen to use size() with its current local semantic)<br>
<br>
These methods (size, keys, values) are useful for people and I think we were not wise to implement them only on top of the local data: this is like preferring efficiency over correctness. This also created a lot of confusion with our users, question like size() doesn't return the correct value being asked regularly. I totally agree that size() returns E (i.e. everything that is stored within the grid, including persistence) and it's performance implications to be documented accordingly. For keySet and values - we should stop implementing them (throw exception) and point users to Will's distributed iterator which is a nicer way to achieve the desired behavior.<br></blockquote><div><br></div><div>We can also implement keySet() and values() on top of the distributed entry iterator and document that using the iterator directly is better.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
><br>
> Radim<br>
><br>
> --<br>
> Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>><br>
> JBoss DataGrid QA<br>
><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
</span>Cheers,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Mircea Markus<br>
Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>