>
> how much memory the Timers can currently use
Timer is currently backed by a DecayingEstimatedHistogramReservoir. [1]
Each DecayingEstimatedHistogramReservoir defaults to allocate [2]
1. *bucketOffsets*: a long array with the length of 164
2. *decayingBuckets*: a long array with the length of
>
> I'm also comfortable with a strict approach where we just list actual
> Apache Cassandra offerings, that also provides good solid clarity to
> users.
That sounds like a reasonable proposal. I just do not know how we can do
that in practice. What is a actual Apache Cassandra offering and how d
+1 to unifying on the same unit for API consistency; micros should be quite
fine for most if not all of our use-cases.
On Fri, Jun 25, 2021 at 8:58 AM Brandon Williams wrote:
> On Fri, Jun 25, 2021 at 6:17 AM Mick Semb Wever wrote:
> >
> > I'm for (1) if this is for 4.1 only. Changes like this
I'm a huge +1 to the sentiments here.
I have to confess that I've been responsible for publishing the updates for
several months now with Mick's mentoring. I publish the content I was
requested to push to the site but as far as review is concerned, the only
review I do is mostly around grammar and
On Fri, Jun 25, 2021 at 6:17 AM Mick Semb Wever wrote:
>
> I'm for (1) if this is for 4.1 only. Changes like this over our annual
> releases should be fine if they are clearly documented, it's what NEWS.txt is
> for.
+1, we have the process in place to handle this.
> There are several options (all for timers specifically):
>
>1. Enforce the consistency of the time unit.
> - Change all JMXTimers to store values in micros and reduce the
> bucket size to 90. The change has no impact on reading the
> statistics. But
> the long[] of Valu
