<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Oct 10, 2014 at 8:51 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Oct 10, 2014, at 15:25, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br>
<br>
> On Fri, Oct 10, 2014 at 5:20 PM, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
><br>
> On Oct 10, 2014, at 15:18, Radim Vansa <<a href="mailto:rvansa@redhat.com">rvansa@redhat.com</a>> wrote:<br>
><br>
> > That we should expose that as one method, not forcing people to<br>
> > implement the sum() themselves.<br>
><br>
> Hmm, isn't the method you mention cache.size() ? :-)<br>
><br>
> Nope, because we decided to make cache.size() precise-but-slow :)<br>
<br>
</span>It's not possible to make it precise unless we provide snapshot isolation /MVCC support.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">IMO the formula Tristan provides is a good enough approximation of the size of the data. And definitely way better than what we currently have.<br>
(Looking at CHM.size() they offer an "accurate" size of the map by counting it in a loop and making sure that the size is reproducible. I don't think that's accurate in the general case, though, as you might count intermediate sizes in that loop).<br></blockquote><div><br></div><div>CHM.size() actually tracks the modCount of each segment and locks all the segments in the final retry, so the result should be accurate. CHMV8 doesn't do that, instead it keeps a striped counter and doesn't try very hard to get a reproducible sum from the counter cells.</div><div><br></div><div>I thought we concluded size() should be stable (and accurate) when there is no write activity, and the way to implement that is with the entry iterator. The result of Tristan's formula can change without any write activity on the cache, just because there is a state transfer in progress.<br></div><div><br></div><div>For monitoring tools I'd rather have separate methods entriesInMemory() -> sum(dataContainer.size()) and entriesInStores() -> sum(cacheStore.size()) that are allowed to rise and fall as nodes join and leave the cache.</div><div><br></div><div>Cheers</div><div>Dan</div><div><br></div></div></div></div>