> The units problem hasn't really been solved well...
Can you elaborate on this? I read your follow-up email, but I still don't
understand what problem hasn't been solved. As far as I can tell, it's
traditional to use milliseconds for configuration and reporting, but higher
resolution units are
Clarifying on (4) units problem - that refers to the software industry in
whole, not just AMQ.
Art
On Wed, Dec 22, 2021 at 12:24 PM Arthur Naseef wrote:
> Thoughts that come to mind (not advocating anything, just putting down
> thoughts);
>
>1. Semver + breaking-changes = new major number
Thoughts that come to mind (not advocating anything, just putting down
thoughts);
1. Semver + breaking-changes = new major number
2. Exposing a new metric while leaving the original unchanged can
eliminate the backward-compatibility problem at the expense of additional
Hi Art-
The metric is arguably broken right now, so my thought is that “fixing” it in
5.17.0 should be the default moving forward.
What else would you suggest?
-Matt Pavlovich
> On Dec 22, 2021, at 11:25 AM, Arthur Naseef wrote:
>
> Hmm, what about the impact to all the consumers of that
Hmm, what about the impact to all the consumers of that metric today?
That's potentially a huge amount of change.
Any thoughts on mitigating the problems for users?
Art
On Wed, Dec 22, 2021 at 7:32 AM Matt Pavlovich wrote:
> Using nanos would eliminate the math division. Might be worth it
Using nanos would eliminate the math division. Might be worth it to cut out a
math operations on longs
Checking for overflow risk.. Java Long.MAX_VALUE in nanoseconds is 292 years.
We should be good with nanos as default vs microseconds.
-Matt
> On Dec 22, 2021, at 6:52 AM, Christopher
+1, I'm not sure if it makes sense to keep the default as millis or make
the new default as nanoseconds.
On Wed, Dec 22, 2021 at 2:09 AM Jean-Baptiste Onofre
wrote:
> +1
>
> It makes sense.
>
> Regards
> JB
>
> > Le 20 déc. 2021 à 16:44, Matt Pavlovich a écrit :
> >
> > Currently, KahaDB stats
