Hi all,
I’m closing the voting on this one. We already had 3 binding votes on this
from Guozhang, Bruno and John.
Thanks everyone!
Sagar.
On Sun, 5 Jun 2022 at 1:53 PM, Sagar wrote:
> Hi All,
>
> I am planning to use the name of the new function as addMetricIfAbsent.
> Let me know if there ar
Hi All,
I am planning to use the name of the new function as addMetricIfAbsent. Let
me know if there are any other suggestions/objections to this.
Also, @Ismael, I agree with Guozhang about not deprecating the existing
functions. Plz let me know if you have any reservations about that.
If we all
I think `addMetricIfAbsent` is a good function name, and like John said
people in the Java world are familiar with its return value semantics as
well.
Regarding deprecating the existing functions, I feel it is not necessary
just for the function semantics difference between `sensors` and `metrics`
So, we have multiple options in terms of names, at this point I actually
liked John's suggestion to use addMetricIfAbsent or something along those
lines.
Regarding the deprecation of sensor/metric method, I am not sure... Would
like to know others' thoughts.
Thanks!
Sagar.
On Wed, Jun 1, 2022 at
Hey Ismael, just checking do you mean the `metric` method instead?
On Tue, May 31, 2022 at 1:45 PM Ismael Juma wrote:
> Should we deprecate the `sensor` method? One other thing to take into
> account is that these methods are meant to be used like a dsl for
> configuring sensors and metrics. So
Should we deprecate the `sensor` method? One other thing to take into
account is that these methods are meant to be used like a dsl for
configuring sensors and metrics. So brevity is a plus (but clarity is
critical still).
Ismael
On Tue, May 31, 2022 at 11:09 AM John Roesler wrote:
> Generally,
Generally, I agree with Ismael that having a new, weird name will make it hard
to keep them straight. Then again, we need to make them different to prevent
confusion about their semantics. To be clear, I'll be a +1 regardless of how we
break this dilemma.
One suggestion: We currently have addMe
Oh yeah there's another metric function which is get-only. I think we
should go ahead with getOrCreateMetric.
Thanks!
Sagar.
On Tue, May 31, 2022 at 10:02 PM Guozhang Wang wrote:
> I'd prefer the getOrCreateMetric function name, since for the existing "
> sensor(String name)" function that only
I'd prefer the getOrCreateMetric function name, since for the existing "
sensor(String name)" function that only takes a single `String` parameter,
its semantics is already "get or create". Whereas the existing
"metric(MetricName)" function's semantics is "get" only. So in my mind, the
inconsistent
Hi Ismael,
I guess in that case, we will have to go with the name *metric*- similar to
*sensor* - which David pointed out above because I think that's the closest
method which either gets or creates a new sensor. Current addMetric in the
Metrics class throw an IllegalArguementException when the me
I think it's confusing to use two completely different naming conventions
in the same class. We either stick with the existing convention or we
create a new one and deprecate old method(s). I am not sure there is enough
value in this case for the latter, but it would be good to hear what others
thi
Hi,
I would also lean towards getOrCreateMetric() for the reasons pointed
out by Sagar. But I am fine either way.
Best,
Bruno
On 30.05.22 10:54, Sagar wrote:
Hi Bruno/David,
Thanks for the suggestions. I would personally lean towards using
getOrCreateMetric as it clearly explains the intent
Hi Bruno/David,
Thanks for the suggestions. I would personally lean towards using
getOrCreateMetric as it clearly explains the intent. Having said that, if
we want to use just metric(similar to sensor), that should also be ok. Just
that I feel getOrCreateMetric is easily understandable.
Thanks!
S
Hi all,
Looking at the current Metrics' API, we have `sensor` which gets or creates
a sensor. How about using `metric` to follow the same naming convention?
Best,
David
On Mon, May 30, 2022 at 9:18 AM Bruno Cadonna wrote:
>
> Hi Sagar,
> Hi Ismael,
>
> what about getOrCreateMetric()?
>
> Best,
Hi Sagar,
Hi Ismael,
what about getOrCreateMetric()?
Best,
Bruno
On 28.05.22 18:56, Sagar wrote:
Hi Ismael,
Actually Bruno suggested renaming it to getMetricOrElseCreate and we
decided to go ahead with that one. These were the only names that we
considered for the KIP.
Thanks!
Sagar.
On S
Hi Ismael,
Actually Bruno suggested renaming it to getMetricOrElseCreate and we
decided to go ahead with that one. These were the only names that we
considered for the KIP.
Thanks!
Sagar.
On Sat, May 28, 2022 at 8:19 PM Ismael Juma wrote:
> Thanks for the KIP. The method makes sense, but the
Thanks for the KIP. The method makes sense, but the name is a bit verbose.
Have we considered a more concise name?
Ismael
On Tue, May 24, 2022, 4:49 AM Sagar wrote:
> Hi All,
>
> I would like to open a voting thread for the following KIP:
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/
Hi All,
This KIP has received 3 binding votes from John, guozhang and Bruno.
Marking the Kip as accepted.
Thanks!
Sagar.
On Tue, 24 May 2022 at 10:29 PM, Bruno Cadonna wrote:
> Hi Sagar,
>
> +1 (binding)
>
> Thanks,
> Bruno
>
> On 24.05.22 18:22, Sagar wrote:
> > Hi John,
> >
> > No worries.
Hi Sagar,
+1 (binding)
Thanks,
Bruno
On 24.05.22 18:22, Sagar wrote:
Hi John,
No worries. addMetric throws an exception which needs to be handled. This
new method removes that need similar to what you have done for the sensor
method.
Thanks!
Sagar.
On Tue, May 24, 2022 at 8:19 PM Guozhang W
Hi John,
No worries. addMetric throws an exception which needs to be handled. This
new method removes that need similar to what you have done for the sensor
method.
Thanks!
Sagar.
On Tue, May 24, 2022 at 8:19 PM Guozhang Wang wrote:
> +1. Thanks Sagar.
>
> Guozhang
>
> On Tue, May 24, 2022 at
+1. Thanks Sagar.
Guozhang
On Tue, May 24, 2022 at 7:31 AM John Roesler wrote:
> Hi again Sagar,
>
> My apologies; I was thinking of the `sensor` method:
> org.apache.kafka.common.metrics.Metrics#sensor(java.lang.String,
> org.apache.kafka.common.metrics.MetricConfig, long,
> org.apache.kafka.c
Hi again Sagar,
My apologies; I was thinking of the `sensor` method:
org.apache.kafka.common.metrics.Metrics#sensor(java.lang.String,
org.apache.kafka.common.metrics.MetricConfig, long,
org.apache.kafka.common.metrics.Sensor.RecordingLevel,
org.apache.kafka.common.metrics.Sensor...)
I'm in fav
Hi Sagar,
Thanks for the KIP!
I’m not at my computer right now, but I think I confronted a similar problem a
while back for the Streams metrics. I think that I already made the “addMetric”
method to be idempotent, so if it’s already registered, the call just returns
the old one instead of crea
Hi All,
I would like to open a voting thread for the following KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-843%3A+Adding+metricOrElseCreate+method+to+Metrics
Thanks!
Sagar.
24 matches
Mail list logo
