Skip to content

Conversation

pulkitmehra
Copy link
Contributor

This PR fixed issue #14066

  • Recursively looking for matching metrics in nested MeterRegistries and return the first found
  • Added test cases.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Sep 17, 2018
}
else {
meters.addAll(registry.find(name).tags(tags).meters());
Collection<Meter> meterFound = registry.find(name).tags(tags).meters();
if (meterFound != null && meterFound.size() > 0) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micrometer guarantees that meterFound is non-null. Could use isEmpty() on second condition.

@@ -112,15 +112,20 @@ private Tag parseTag(String tag) {
return Tag.of(parts[0], parts[1]);
}

private void collectMeters(List<Meter> meters, MeterRegistry registry, String name,
Iterable<Tag> tags) {
private boolean findFirstMatchingMeters(List<Meter> meters, MeterRegistry registry,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than modifying a parameter, this method could simply return a Collection.

@pulkitmehra
Copy link
Contributor Author

@jkschneider , please review.

meters.addAll(registry.find(name).tags(tags).meters());
Collection<Meter> metersFound = registry.find(name).tags(tags).meters();
if (!metersFound.isEmpty()) {
return new ArrayList<>(metersFound);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need to wrap this. The list returned is already an immutable copy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jkschneider , the reason I am wrapping it into List is to avoid returning Collection from this method.

Collection<Meter> metersFound = registry.find(name).tags(tags).meters();

If we return Collection, the MetricEndpoint methods should be refactored so that Collection could be pass around instead of List interface OR the return type should be downcasted to List (which is dangerous as we dont have control on MeterRegistry#find)

Changing MetricEndpoint methods to pass Collection is minor refactoring, with following highlight.

will be change to

meters.iterator().next().getId();

Please confirm should I go ahead and do this minor change?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The minor refactoring seems preferable to me to generating extra garbage in this case, as minor as that will be.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jkschneider, pls review.

@philwebb philwebb added type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels Sep 21, 2018
@philwebb philwebb added this to the 2.0.x milestone Sep 21, 2018
@philwebb philwebb added the for: merge-with-amendments Needs some changes when we merge label Sep 21, 2018
@philwebb philwebb changed the title 14066: finding first matching metrics from nested MeterRegistries inside MetricEndpoint Finding first matching metrics from nested MeterRegistries inside MetricEndpoint Sep 21, 2018
@philwebb philwebb changed the title Finding first matching metrics from nested MeterRegistries inside MetricEndpoint Metric endpoint is summing up same metric Sep 21, 2018
@pulkitmehra
Copy link
Contributor Author

@philwebb , @jkschneider , the issue is closed but PR is still open. Is there anything l can do to help you merge it?

@snicoll
Copy link
Member

snicoll commented Sep 25, 2018

The issue has been closed because this PR supersedes it. All is good, we just need some time to review it.

@philwebb philwebb self-assigned this Oct 11, 2018
philwebb added a commit that referenced this pull request Oct 11, 2018
* pr/14497:
  Polish "Stop MetricsEndpoint from summing up same metrics"
  Stop MetricsEndpoint from summing up same metrics
@philwebb philwebb closed this in 950480d Oct 11, 2018
@philwebb
Copy link
Member

@pulkitmehra Thanks for the fix. This is now in 2.0.x and master.

@philwebb philwebb modified the milestones: 2.0.x, 2.1.0.RC1 Oct 11, 2018
@philwebb philwebb modified the milestones: 2.1.0.RC1, 2.0.6 Oct 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: merge-with-amendments Needs some changes when we merge type: bug A general bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants