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 <ttarrant(a)redhat.com>
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 <dereed(a)redhat.com> 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
>>> infinispan-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev