KAFKA-9152; Improve Sensor Retrieval#7928
Conversation
1929d2d to
b8fb712
Compare
|
@cadonna I learned a lot from your reviews Thank you very much :) i'm code update!! |
cadonna
left a comment
There was a problem hiding this comment.
The PR is looking better. I have still some comments.
b8fb712 to
acfd29d
Compare
|
@cadonna Thank you!! |
cadonna
left a comment
There was a problem hiding this comment.
The PR looks good to me. I have just a few minor comments.
|
Call for final review: @bbejeck @mjsax @guozhangwang @vvcephei Does anybody of you know why the builds are not triggered for this PR? |
|
@highluck Could you please better describe this PR in the PR message at the top of this page underneath the PR title? |
|
retest this please |
acfd29d to
0dde9df
Compare
|
@cadonna @guozhangwang |
0dde9df to
a6a5568
Compare
@cadonna I'm looking into it. It seems the builds may get triggered, but for some reason, the Github page isn't updating. Retest this please. |
|
Retest this please |
There was a problem hiding this comment.
Why is(equalToObject(sensor))) and not just is(sensor)?
There was a problem hiding this comment.
That is on me. In this verification it is important to check for reference equality, because you want that threadLevelSensor() returns the sensor that is registered in the Metrics object or that was created by Metrics#sensor().
There was a problem hiding this comment.
Yeah, I get that we want to make sure the same instance is returned. But since Sensor doesn't override equals, is(sensor) should still do an instance equality check. It's really a minor point, so I don't care too much if we keep it as is.
There was a problem hiding this comment.
I used equalToObject() because it makes the intent more explicit.
There was a problem hiding this comment.
Fair enough, let's just leave it as is then. Thanks for the explanation.
There was a problem hiding this comment.
ditto and same for tests below, I won't repeat this comment.
|
retest this please |
|
@highluck the failure is related See comment #7928 (comment) above |
f979076 to
e55a741
Compare
|
@bbejeck |
|
Retest this please. |
|
@bbejeck |
|
@highluck Hard to say, but it seems like a flaky test. What test does throw this exception? |
|
@cadonna But there is no problem in my local test |
|
Retest this please |
1 similar comment
|
Retest this please |
|
Java 8 failed with Java 11 passed Retest this please. |
|
@bbejeck |
|
JDK 11/Scala 2.13 failed with JDK 8/Scala 2.12 failed with Jenkins specific error |
|
Retest this please. |
|
Merged #7928 into trunk. |
|
Thanks @highluck for the contribution! |
Conflicts and/or compiler errors due to the fact that we temporarily reverted the commit that removes Scala 2.11 support: * Exit.scala: replace SAMs with anonymous inner classes. * MiniKdc.scala: take upstream changes. # By A. Sophie Blee-Goldman (1) and others # Via Jason Gustafson * apache-github/trunk: KAFKA-9254; Overridden topic configs are reset after dynamic default change (apache#7870) MINOR: MiniKdc JVM shutdown hook fix (apache#7946) KAFKA-9152; Improve Sensor Retrieval (apache#7928) Correct exception message in DistributedHerder (apache#7995) KAFKA-7317: Use collections subscription for main consumer to reduce metadata (apache#7969) KAFKA-9181; Maintain clean separation between local and group subscriptions in consumer's SubscriptionState (apache#7941) KAFKA-7737; Use single path in producer for initializing the producerId (apache#7920) # Conflicts: # core/src/test/scala/kafka/security/minikdc/MiniKdc.scala
This ticket shall improve two aspects of the retrieval of sensors:
https://issues.apache.org/jira/browse/KAFKA-9152
Currently, when a sensor is retrieved with *Metrics.*Sensor() (e.g. ThreadMetrics.createTaskSensor()) after it was created with the same method *Metrics.*Sensor(), the sensor is added again to the corresponding queue in Sensors (e.g. threadLevelSensors) in StreamsMetricsImpl. Those queues are used to remove the sensors when removeAllLevelSensors() is called. Having multiple times the same sensors in this queue is not an issue from a correctness point of view. However, it would reduce the footprint to only store a sensor once in those queues.
When a sensor is retrieved, the current code attempts to create a new sensor and to add to it again the corresponding metrics. This could be avoided.
Both aspects could be improved by checking whether a sensor already exists by calling getSensor() on the Metrics object and checking the return value.
Committer Checklist (excluded from commit message)