mlbiscoc commented on code in PR #3384:
URL: https://github.com/apache/solr/pull/3384#discussion_r2153298468
##########
solr/core/src/java/org/apache/solr/metrics/SolrMetricProducer.java:
##########
@@ -40,20 +41,16 @@ static String getUniqueMetricTag(Object o, String
parentName) {
}
/**
- * Initialize metrics specific to this producer.
- *
- * @param parentContext parent metrics context. If this component has the
same life-cycle as the
- * parent it can simply use the parent context, otherwise it should
obtain a child context
- * using {@link SolrMetricsContext#getChildContext(Object)} passing
<code>this</code> as the
- * child object.
- * @param scope component scope
+ * Deprecated entry point for initializing metrics. TODO SOLR-17458: This
will be removed Change
+ * to only take attributes completely removing Dropwizard
*/
- void initializeMetrics(SolrMetricsContext parentContext, String scope);
+ void initializeMetrics(SolrMetricsContext parentContext, Attributes
attributes, String scope);
Review Comment:
> We don't need an attribute for the registry so long as our metrics are
reasonably differentiated / clear. We can change our mind in the future with
basically no disturbance, I suppose. I wouldn't get rid of SolrMetricsContext
yet. AB also kind of recommended keeping it to reduce the review/impact.
If we keep `SolrMetricsContext` then it might actually then make sense to
just place attributes in here like you said. The `Base Attributes` can still
sit in here then be augmented with additional attributes on the metric no
differently and it would significantly reduce number of PR line changes. Also
gives `SolrMetricContext` a use besides just being a passthrough to
`metricManager`. Currently Solr creates a new `SolrMetricsContext` per
registry, but we will instead need to create on per implementation of
`SolrMetricProducer` . I'm going to play with this and see if it makes sense
otherwise I'll keep it as is.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
