Looks like we all agree on option 1. I have submitted a patch to the trunk
branch. It unifies the duration unit and defaults to micros. As a result,
all timers will start to record time values in micros instead of nanos.
Please let me know if there is any concern with the change.
- Yifan
On Fri,
>
> 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
+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
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
Hi,
In the current codebase, JMXTimer exposes its attributes in inconsistent
time units. The percentiles, Mean and DurationUnit attributes are using
micros. But the Values and RecentValues are based on nanos, since the
underlying Timer collects the time values in nanos.
The inconsistency leads to
