CompositeMeters don't ignore NoopMeters when forwarding value get calls to child. #1441
Labels
Milestone
Comments
This was referenced Jun 17, 2019
shakuzen
added
bug
jonatan-ivanov
added a commit
to jonatan-ivanov/micrometer
that referenced
this issue
Sep 22, 2023
When a CompositeMeterRegistry is used and one of its CompositeMeters is polled (its value is fetched), the returned value can depend on the order of the registries inside of the composite if the composite contains a registry that has any NoopMeters. Example: a CompositeMeterRegistry contains two registries, A and B. We create a counter in the composite and increment it once. After this both A and B contain one counter but lets say that in A the counter is ignored so it will be noop. When the count called on CompositeCounter, it can return either 0 (if NoopCounter was used) or 1 (if the non-noop counter was used). In order to fix this, we can ignore the NoopMeters when Meters are polled in a composite registry. Closes micrometer-metricsgh-1441
JannickKemming1997
pushed a commit
to otto-ec/pdh-da_micrometer
that referenced
this issue
Jan 16, 2024
When a CompositeMeterRegistry is used and one of its CompositeMeters is polled (its value is fetched), the returned value can depend on the order of the registries inside of the composite if the composite contains a registry that has any NoopMeters. Example: a CompositeMeterRegistry contains two registries, A and B. We create a counter in the composite and increment it once. After this both A and B contain one counter but lets say that in A the counter is ignored so it will be noop. When the count called on CompositeCounter, it can return either 0 (if NoopCounter was used) or 1 (if the non-noop counter was used). In order to fix this, we can ignore the NoopMeters when Meters are polled in a composite registry. Closes micrometer-metricsgh-1441
JannickKemming1997
pushed a commit
to otto-ec/pdh-da_micrometer
that referenced
this issue
Jan 25, 2024
When a CompositeMeterRegistry is used and one of its CompositeMeters is polled (its value is fetched), the returned value can depend on the order of the registries inside of the composite if the composite contains a registry that has any NoopMeters. Example: a CompositeMeterRegistry contains two registries, A and B. We create a counter in the composite and increment it once. After this both A and B contain one counter but lets say that in A the counter is ignored so it will be noop. When the count called on CompositeCounter, it can return either 0 (if NoopCounter was used) or 1 (if the non-noop counter was used). In order to fix this, we can ignore the NoopMeters when Meters are polled in a composite registry. Closes micrometer-metricsgh-1441
jkemming
added a commit
to jkemming/micrometer
that referenced
this issue
Feb 13, 2024
jkemming
added a commit
to jkemming/micrometer
that referenced
this issue
Feb 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For example, consider a
CompositeCountermade up ofCounters from two registries where one registry may have filtered or otherwise produces aNoopMeter. InvokingCompositeCounter.count()may result in either0from theNoopMeteror some other value from the otherCounter.The problem appears to be in
AbstractCompositeCounter.firstChild()as it doesn't filter outNoopMeterswhen delegating to the child. Alternatively aCompositeMetercould avoid placing anyNoopMeters in its collection of child meters.The text was updated successfully, but these errors were encountered: