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