[infinispan-dev] Distributed Counter Discussion

[Pedro Ruivo]

Comments inline

On 03/14/2016 09:27 PM, Sanne Grinovero wrote:
> On 14 March 2016 at 19:14, Pedro Ruivo <pedro at infinispan.org> wrote:
>
> As a user, how do I get a Counter instance? From a the CacheContainer interface?

You can get a Counter from a CounterManager. The CounterManager is 
associated to the CacheManager.

I have two options to get the CounterManager:

CacheManager.as(CouterManager.class), as discussed during the Rome 
meeting (2015). This will change the API in the core but it allows to 
introduce the other building blocked (locks, sequences, latches, ...)

The other alternative I have in mind is CounterMager.get(CacheManager). 
The only advantage I see is no need to change the API in core.

guys... comment what alternative do you prefer...

>
> Will they have their own configuration section in the configuration file?

I have no idea here... probably something like the cache store 
configurations would work.

>> long get()       //current value. may return stale value due to concurrent
>> operations to other nodes.
>
> This is what puzzles me the most. I'm not sure if the feature is
> actually useful, unless we can clearly state how far outdated the
> value could be.
>
> I think a slightly more formal definition would be in order. For
> example I think it would be acceptable to say that this will return a
> value from the range of values the primary owner of this counter was
> holding in the timeframe between the method is being invoked and the
> time the value is returned.
>
> Could it optionally be integrated with Total Order ? Transactions?

That's why we are having this discussion. If someone heard some 
requirements from an user, it would be good to write them here.

IMO, at least, the get() must include all the finished operations in the 
local node.

>>
>> long getMin/MaxThreshold() //returns the min and max threshold value
>
> "threshold" ??

See Tristan's reply.

>
> I'd prefer a single interface, with reduced redundancy.
> For example, is there really a benefit in having a "void increment()"
> and also a "long addAndGet()" ? [Besides The fact that only the first
> one can benefit of an async option]
>
> Besides, I am no longer sure that it's good thing that methods in
> Infinispan can be async vs sync depending on configuration switches;
> I'd rather make it explicit in the signature and simplify the
> configuration by removing such a flag.
>
> Making the methods which are async-capable to look "explicitly async"
> should also allow us to add completeable futures & similar.

So, lets revamp the API. We can drop the AtomiCounter and create a 
simple Counter interface like:

String getName()
CompletableFuture<Long> addAndGet()
long get()
void reset()

It is the simplest we can get and it covers all the semantics we need so 
far. If something does not fit, we can start improving it.

>
> Rather than a split organized on the backing implementation details,
> I'd prefer to see a split based on purpose of the counter.

So, what about multiple CounterManager where in each implementation we 
specified what semantic the Counter created ensures?

>
> For example JGroups has different styles of counters: one might need
> one to do an atomic increment which is monotonically increasing across
> the whole cluster - from the point of view from an omniscent observer
> - but in many cases we just need the generation of a guarantee of a
> monotonic unique number: that allows for example to have each node
> pre-allocate a range of values and pre-fetch a new block while its
> running out of values.

you lost me in the pre-allocate range of values. I think you are talking 
about sequences (we also discussed that in Rome) but I don't think it 
should be the primary objective of a counter.

>
> For some systems this is not acceptable because a failing server might
> result in some of its allocated numbers to not ever be used, so
> creating gaps; for others it's not acceptable that the figures
> returned by the "monotonic counter" are not monotonic across each
> other when confronting results from different cluster nodes, but for
> many use cases that's acceptable. My point being that we need to be
> able to choose between these possible semantics.
>
> As an Infinispan consumer being able to express such details is
> essential, while having to choose between "backed by JGroups counters"
> or not is irrelevant and actually makes it harder.
>
> In terms of Infinispan integration, the most important point I'd like
> to see is persistence: i.e. make sure you can store them in a
> CacheStore.
> How we do that efficiently will also affect design; for example I was
> expecting to see a Counter as something which is stored in a Cache, so
> inheriting details such as configured CacheStore(s) and number of
> owners.

I'm ok to support persistence but I don't see any advantage. Does anyone 
have a use case for it?