[infinispan-dev] Distributed Counter Discussion

[Sanne Grinovero]

On 7 April 2016 at 13:28, Tristan Tarrant <ttarrant at redhat.com> wrote:
> I think the main interface definition (as it is) is fine, but it needs
> to be subclassed into two different behaviours:
>
> - "sync": the value returned by the CF is consistent across the cluster
> - "eventually consistent": the value returned by the CF might be stale
> (maybe return its latest "localh" value)

For the "eventually consistent" case, returning a local value might be
fine but you'd need to define also how writes are merged and what
guarantees it aims to provide (or which we want to intentionally
ignore).

And what about the sequence use case? I guess it can wait, just
tracking the need for that too.

Thanks,
Sanne

>
> Tristan
>
> On 30/03/2016 12:34, Sanne Grinovero wrote:
>> Hi Pedro,
>> there have been many questions on this thread pointing out the need to
>> clarify the definition and which requirements it aims to solve. I
>> don't think we can comment on the API proposal without making that
>> clear first?
>>
>> It seems there was some consensus that this doesn't help for the
>> APIMan use case; could we clarify the goal and use cases then?
>>
>> thanks,
>> Sanne
>>
>> On 29 March 2016 at 18:25, Pedro Ruivo <pedro at infinispan.org> wrote:
>>> == Status update ==
>>>
>>> Hi all,
>>>
>>> The work in progress can be found in [1].
>>>
>>> The main interface is:
>>>
>>> CompletableFuture<Long> addAndGet(long)
>>>
>>> The CompletableFuture will allow to cover a more use cases, for example,
>>> if you need to count the number of visits, you can increment without
>>> waiting it to complete. On other hand, if you need "unique ids", it is
>>> possible to increment and wait for the result.
>>>
>>> * Let me know any concerns with it.
>>>
>>> Currently, two types of counters can be returned by the counter manager:
>>> "unlimited" and limited (i.e. with thresholds).
>>>
>>> "Unlimited" is actually limited to Long.MAX_VALUE but will never throw
>>> any exception when reached.
>>> The limited version throws a CounterException when the min or max
>>> threshold is reached.
>>> In both cases, it doesn't overflow the counter value.
>>>
>>> Currently, I'm working in the notification mechanism. So, just ignore
>>> that part of the code :)
>>>
>>> Moving to the next problem, I need an opinion how to create the counter
>>> manager.
>>>
>>> The current implementation is using a private cache. It has the
>>> advantage of starting the cache when a cache manager starts, however, it
>>> is a bit difficult to configure (e.g. persistence). Also, it does not
>>> allow different configuration for the counter (replicated vs
>>> distributed, persisted or not).
>>>
>>> Another alternative, it to construct the counter manager with the cache
>>> manager and a cache name. This looks simpler and it allows the user to
>>> configure it properly and have different counter manager with different
>>> configurations.
>>>
>>> * Comments are welcome.
>>>
>>> Cheers,
>>> Pedro
>>>
>>> [1] https://github.com/pruivo/infinispan/tree/t_counters/distributed-counter
>>> _______________________________________________
>>> 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
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev