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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev