[
https://issues.apache.org/jira/browse/SOLR-9959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15938183#comment-15938183
]
Andrzej Bialecki commented on SOLR-9959:
-----------------------------------------
This second round removes {{SolrInfoMBean.getStatistics()}} and replaces it
with metrics. Even though the diff is sizeable it was a pretty straightforward
replacement. All tests and precommit pass.
However, there are some aspects of this round of changes that may raise a few
eyebrows ;) so please speak up if they concern you:
* back-compatibility is NOT preserved, in fact it's broken both at the level of
Java APIs and REST APIs. I made sure that all statistics that were available
via /admin/mbeans are also present in the metrics API, but metric paths are
different from the /admin/mbeans paths, even though the metric names (their
last elements) are almost always the same (I changed a few nonCamelCase names).
* SolrCache implementations used to return snapshots of their internal state as
statistics, including optional details such as cache entries. This didn't play
well with the metrics API, where all individual metrics should be registered in
advance, and then unregistered when they are no longer necessary, because we
didn't know when cache entries would be evicted. The solution was to implement
a dynamic map-like metric {{MetricsMap}} that is registered as a single metric
but returns a {{Map}} value. We may want to use the same approach for jetty
metrics, too.
* metrics API doesn't maintain the origin of metric instances, ie. the mapping
back from a particular metric to a component that registered the metric is not
supported. This makes it impossible to ask the API for all metrics for a
component, which is what the {{/admin/mbeans}} used to provide. On the other
hand, the {{/admin/metrics}} API provides a much more structured view of
related metrics even if they come from different components.
TODOs:
* {{SolrCore.infoRegistry}} used to be central to the JMX reporting. Now that
this functionality has been separated to JmxReporter and metrics API it only
serves a limited purpose as an informative registry of plugins (plugin
lifecycle is not managed by this registry). This information is then provided
via PluginInfoHandler and SolrInfoMBeanHandler. We should decide whether to add
more useful information here or to remove it completely.
> SolrInfoMBean-s category and hierarchy cleanup
> ----------------------------------------------
>
> Key: SOLR-9959
> URL: https://issues.apache.org/jira/browse/SOLR-9959
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: metrics
> Affects Versions: master (7.0)
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Blocker
> Fix For: master (7.0)
>
>
> SOLR-9947 changed categories of some of {{SolrInfoMBean-s}}, and it also
> added an alternative view in JMX, similar to the one produced by
> {{SolrJmxReporter}}.
> Some changes were left out from that issue because they would break the
> back-compatibility in 6.x, but they should be done before 7.0:
> * remove the old JMX view of {{SolrInfoMBean}}-s and improve the new one so
> that it's more readable and useful.
> * in many cases {{SolrInfoMBean.getName()}} just returns a FQCN, but it could
> be more informative - eg. for highlighter or query plugins this could be the
> symbolic name of a plugin that users know and use in configuration.
> * top-level categories need more thought. On one hand it's best to minimize
> their number, on the other hand they need to meaningfully represent the
> functionality of components that use them. SOLR-9947 made some cosmetic
> changes, but more discussion is necessary (eg. QUERY vs. SEARCHHANDLER)
> * we should consider removing some of the methods in {{SolrInfoMBean}} that
> usually don't return any useful information, eg. {{getDocs}}, {{getSource()}}
> and {{getVersion()}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
