[infinispan-dev] Distributed Counter Discussion

[Tristan Tarrant]

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)

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