[infinispan-dev] About size()

[Radim Vansa]

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 at 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 at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA