[infinispan-dev] Distributed Counter Discussion

[Galder Zamarreño]

Good start but rather than coming out with a general design for a counter, I'd try to start coming out with functionality needed for the most commonly use cases for counters, e.g.

e.g. if you're counting number of visits to your website, you only need an incrementing counter (and maybe a reset to be called at the end of the day/week/month/year?) but you'll never decrement, precision not hugely important? Could you assume you always increment by 1? It might be more efficient to increment by N...

e.g. if you're counting number of users logged in at one point to your website, then you need a counter that both increments and decrements, precision not hugely important? You probably don't want reset operation? Moreover, could you assume you always increment/decrement by 1?

e.g. if using a counter to generate a unique identifier that always increases, you need only increment but precision must be guaranteed, so after increasing and retrieving an old value can't be retrieved. You probably don't want reset operation? You can probably assume that increment is only by 1.

...etc

And based on those, see what kind of API you need for each use case. There might be many more use cases but I'd rather start there than head directly to specifying operations. My main objective is to avoid that someone that wants to count number of visits to a website does not end up calling a method that would not make sense for its use case. Doing this might not be 100% avoidable but hope you see my point.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 14 Mar 2016, at 20:14, Pedro Ruivo <pedro at infinispan.org> wrote:
> 
> Hi everybody,
> 
> Discussion about distributed counters.
> 
> == Public API ==
> 
> interface Counter
> 
> String getName() //counter name
> long get()	 //current value. may return stale value due to concurrent 
> operations to other nodes.
> void increment() //async or sync increment. default add(1)
> void decrement() //async or sync decrement. default add(-1)
> void add(long)   //async or sync add.
> void reset()     //resets to initial value
> 
> Note: Tried to make the interface as simple as possible with support for 
> sync and async operations. To avoid any confusion, I consider an async 
> operation as happening somewhat in the future, i.e. eventually 
> increments/decrements.
> The sync operation happens somewhat during the method execution.
> 
> interface AtomiCounter extends Counter
> 
> long addAndGet()       //adds a returns the new value. sync operation
> long incrementAndGet() //increments and returns the new value. sync 
> operation. default addAndGet(1)
> long decrementAndGet() //decrements and returns the new value. sync 
> operation. default addAndGet(-1)
> 
> interface AdvancedCounter extends Counter
> 
> long getMin/MaxThreshold() //returns the min and max threshold value
> void add/removeListener()  //adds a listener that is invoked when the 
> value change. Can be extended to notify when it is "reseted" and when 
> the threshold is reached.
> 
> Note: should this interface be splitted?
> 
> == Details ==
> 
> This is what I have in mind. Two counter managers: one based on JGroups 
> counter and another one based on Infinispan cache.
> The first one creates AtomicCounters and it first perfectly. All 
> counters are created with an initial value (zero by default)
> The second generates counters with all the options available. It can mix 
> sync/async operation and all counters will be in the same cache. The 
> cache will be configure by us and it would be an internal cache. This 
> will use all the features available in the cache.
> 
> Configuration-wise, I'm thinking about 2 parameters: number of backups 
> and timeout (for sync operations).
> 
> So, comment bellow and let me know alternatives, improvement or if I 
> missed something.
> 
> ps. I also consider implement a counter based on JGroups-raft but I 
> believe it is an overkill.
> ps2. sorry for the long email :( I tried to be shorter as possible.
> 
> Cheers,
> Pedro
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev