Hi All,
I've just been refactoring the code I'm going to talk about now, so
you'll probably need to update to follow this discussion along in the
code...
org.terracotta.counter is a pretty simple package. It just provides a
bunch of statistics counters. They are not currently clusterable, and
so are really just util classes. One thing I'm thinking about for
clarity is to move classes that some people might think of as
clusterable that aren't into packages that hint at their non clustered
nature, thoughts on this? Also I'm a bit suspicious on how much of
this we need, BoundedCounter, RateCounter and RateCounterImpl are not
currently used by any TC code that I could find, do people think these
are useful enough to keep around?
Anyone here are some of my questions on this stuff...
interface Statistic
pretty simplistic this: i have no questions on it, anyone else?
interface Counter
1: getAndSet implies that counters are thread safe (getAndSet would
be atomic I'd assume). Should the interface require all
implementations have atomic ops)
2: if we allow non thread safe impls should getAndSet be defined here
or not (and if so should not atomic getAndSets be disallowed)
interface RateCounter
1: rate counter provides no getAndSet, but does provide getAndReset
through Statistic, should it require implementations to be thread safe
with an atomic getAndReset?
2: should rate counter return a float not a long? - if we stay with
long what should a denominator of zero represent.
interface SampledStatistic
i have no questions anyone else?
interface TimeStampedStatisticValue
i have no questions anyone else?
class SimpleCounterImpl
1: getAndReset should reset to 0 or initialValue?
2: numerical overflow/underflow - exceptions, wrapping?
class BoundedCounter
1: increment/decrement are not currently atomic - they should be I
would guess
2: should sets beyond the bound range be ignored, or just push the
value to the bound?
class RateCounterImpl
just a straight impl of RateCounter so no questions here
class SampledStatisticImpl
straight up fixed rate, fixed buffer size sampling - i can't think of
anything complex here...
class SampledStatisticManager
lifecycle management for the above to make sure timers are shutdown.
1: Should we do shutdown cleanup with weak references in the timer
jobs, and self cancelling timers instead?
2: If we do that would people prefer passing in a Timer/
ScheduledExecutorService as an option, and have the default timer as a
static member of the impl class?
All input on any of these questions (or any other questions) will be
gratefully received,
Chris
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
