[
https://issues.apache.org/jira/browse/SOLR-11291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16152591#comment-16152591
]
Christine Poerschke commented on SOLR-11291:
--------------------------------------------
(Disclosure: Omar and I are in the same team and I've already internally seen
and had input into the attached patch.)
The motivation for the proposed changes is, as Omar mentioned, to support new
reporters that allow metrics to be reported on a per-core basis. I.e. the
reporter itself directly 'knows' which core it is reporting metrics for; this
is similar to but slightly different from the [Core Metric
Registry|https://lucene.apache.org/solr/guide/6_6/metrics-reporting.html#core-solrcore-registry]
functionality.
Since SOLR-9858 in Solr 7.0 the SolrShardReporter reports selected metrics from
replicas to the shard leader. If the {{group="shard"}} attribute is configured
then SolrCoreMetricManager calls SolrMetricManager.loadShardReporters which
eventually calls
{code}
((SolrShardReporter)reporter).setCore(core);
{code}
so that the SolrShardReporter 'knows' which core it is reporting metrics for.
This ticket proposes the creation of an abstract class:
{code}
abstract public class SolrCoreReporter extends FilteringSolrMetricReporter {
protected SolrCore core;
... constructor here ...
public void setCore(SolrCore core) { this.core = core; }
public SolrCore getCore() { return core; }
}
{code}
SolrCoreReporter is a tentative name e.g. it could be renamed to (say)
SolrReplicaReporter or similar if SolrCoreReporter is too close to the Core
Metric Registry concept. The existing SolrShardReporter would extend the new
abstract class.
Omar's patch includes a test example reporter SolrConsoleReporter which extends
the new abstract class and via
{code}
ant test -Dtestcase=SolrConsoleReporterTest
{code}
always and
{code}
ant test -Dtestcase=SolrCloudReportersTest
{code}
part of the time via randomization the SolrConsoleReporter class is used.
(Slightly longer than anticipated preamble, oops, now here's a question.)
In its current form the patch includes the addition of a new
{{SolrInfoBean.Group.replica}} enum choice and SolrMetricManager changes like
this:
{code}
...
+ public void loadReplicaReporters(PluginInfo[] pluginInfos, SolrCore core) {
+ doLoadSolrCoreReporters(pluginInfos, core, SolrInfoBean.Group.replica);
+ }
+
public void loadShardReporters(PluginInfo[] pluginInfos, SolrCore core) {
+ doLoadSolrCoreReporters(pluginInfos, core, SolrInfoBean.Group.shard);
+ }
+
+ private void doLoadSolrCoreReporters(PluginInfo[] pluginInfos, SolrCore
core, SolrInfoBean.Group group) {
...
{code}
i.e. there is overlap between the existing {{SolrInfoBean.Group.shard}} code
and the new {{SolrInfoBean.Group.replica}} code.
Might such overlap be confusing from a user's point of view?
If it would be confusing and if the new abstract class was called
{{SolrReplicaReporter}} then might a solution be to deprecate
{{SolrInfoBean.Group.shard}} in favour of {{SolrInfoBean.Group.replica}}?
[~ab] - would you have any thoughts on this?
> Adding Solr Core Reporter
> -------------------------
>
> Key: SOLR-11291
> URL: https://issues.apache.org/jira/browse/SOLR-11291
> Project: Solr
> Issue Type: New Feature
> Components: metrics
> Reporter: Omar Abdelnabi
> Priority: Minor
> Attachments: SOLR-11291.patch
>
>
> Adds a new reporter, SolrCoreReporter, which allows metrics to be reported on
> per-core basis.
> Also modifies the SolrMetricManager and SolrCoreMetricManager to take
> advantage of this new reporter.
> Adds a test/example that uses the SolrCoreReporter. Also adds randomization
> to SolrCloudReportersTest.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
