If you have one local and one shared cache store, how should the command behave?
a) distexec/MR sum of cache.withFlags(SKIP_REMOTE_LOOKUP, SKIP_BACKUP_ENTRIES).size() from all nodes? (note that there's no SKIP_BACKUP_ENTRIES flag right now), where this method returns localStore.size() for first non-shared cache store + passivation ? dataContainer.size(SKIP_BACKUP_ENTRIES) : 0) b) distexec/MR sum of sharedStore.size() + passivation ? sum of dataContainer.size(SKIP_BACKUP_ENTRIES) : 0 c) MR that would count the entries d) wrapper on distributed entry iteration with converters set to return 0-sized entries And what about nodes with different configuration? Radim On 10/06/2014 01:57 PM, Sanne Grinovero wrote: > On 6 October 2014 12:44, Tristan Tarrant <[email protected]> wrote: >> I think we should provide correct implementations of size() (and others) >> and provide shortcut implementations using our usual Flag API (e.g. >> SKIP_REMOTE_LOOKUP). > Right that would be very nice. Same for CacheStore interaction: all > cachestores should be included unless skipped explicitly. > > Sanne > >> Tristan >> >> On 06/10/14 12:57, Sanne Grinovero wrote: >>> On 3 October 2014 18:38, Dennis Reed <[email protected]> wrote: >>>> Since size() is defined by the ConcurrentMap interface, it already has a >>>> precisely defined meaning. The only "correct" implementation is E. >>> +1 >>> >>>> The current non-correct implementation was just because it's expensive >>>> to calculate correctly. I'm not sure the current impl is really that >>>> useful for anything. >>> +1 >>> >>> And not just size() but many others from ConcurrentMap. >>> The question is if we should drop the interface and all the methods >>> which aren't efficiently implementable, or fix all those methods. >>> >>> In the past I loved that I could inject "Infinispan superpowers" into >>> an application making extensive use of Map and ConcurrentMap without >>> changes, but that has been deceiving and required great care such as >>> verifying that these features would not be used anywhere in the code. >>> I ended up wrapping the Cache implementation in a custom adapter which >>> would also implement ConcurrentMap but would throw a RuntimeException >>> if any of the "unallowed" methods was called, at least I would detect >>> violations safely. >>> >>> I still think that for the time being - until a better solution is >>> planned - we should throw exceptions.. alas that's an old conversation >>> and it was never done. >>> >>> Sanne >>> >>> >>>> -Dennis >>>> >>>> On 10/03/2014 03:30 AM, Radim Vansa wrote: >>>>> Hi, >>>>> >>>>> recently we had a discussion about what size() returns, but I've >>>>> realized there are more things that users would like to know. My >>>>> question is whether you think that they would really appreciate it, or >>>>> whether it's just my QA point of view where I sometimes compute the >>>>> 'checksums' of cache to see if I didn't lost anything. >>>>> >>>>> There are those sizes: >>>>> A) number of owned entries >>>>> B) number of entries stored locally in memory >>>>> C) number of entries stored in each local cache store >>>>> D) number of entries stored in each shared cache store >>>>> E) total number of entries in cache >>>>> >>>>> So far, we can get >>>>> B via withFlags(SKIP_CACHE_LOAD).size() >>>>> (passivation ? B : 0) + firstNonZero(C, D) via size() >>>>> E via distributed iterators / MR >>>>> A via data container iteration + distribution manager query, but only >>>>> without cache store >>>>> C or D through >>>>> getComponentRegistry().getLocalComponent(PersistenceManager.class).getStores() >>>>> >>>>> I think that it would go along with users' expectations if size() >>>>> returned E and for the rest we should have special methods on >>>>> AdvancedCache. That would of course change the meaning of size(), but >>>>> I'd say that finally to something that has firm meaning. >>>>> >>>>> WDYT? >>>>> >>>>> Radim >>>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> _______________________________________________ >>> infinispan-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >>> >> _______________________________________________ >> infinispan-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <[email protected]> JBoss DataGrid QA _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
