That's along the lines of what I described earlier, but it has the downside
of not being returned in the various get methods (and the internal maps) in
StatsCollection - I don't think the fast counter can be a subtype of
Counter so it will have to be dealt with as a new type of metric which will
impact downstream uses, such as the metrics endpoints and, in our case, the
processes pushing metrics to our metric collection. I'm out of the country
this weekend but will give it some thought and revisit it next week.
On Mar 14, 2014 4:51 PM, "Moses Nakamura" <notifications@github.com> wrote:

> In src/main/scala/com/twitter/ostrich/stats/StatsCollection.scala:
>
> > @@ -175,10 +175,6 @@ class StatsCollection extends StatsProvider with JsonSerializable {
> >
> >    def getCounter(name: String): Counter = getCounter(name, newCounter(name))
> >
> > -  def makeCounter(name: String, atomic: AtomicLong): Counter = {
>
> Right now they're in finagle-core<https://github.com/twitter/finagle/blob/master/finagle-core/src/main/scala/com/twitter/finagle/stats/StatsReceiver.scala#L10>,
> although we're trying to move them into a util-stats library, it's slow
> going since we want to keep the c.t.f.s.Counter abstractions compiling.
>
> Maybe the right thing to do is to just make people opt into the fast
> counter explicitly. How about you have to construct a LongAdderCountervia Stats.getFastCounter if you want fast stats? It's a bummer because it
> means that old users don't just get magically faster, but it preserves
> correctness.
>
> --
> Reply to this email directly or view it on GitHub<https://github.com/twitter/ostrich/pull/67/files#r10613338>
> .
>