[
https://issues.apache.org/jira/browse/SOLR-13858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17120747#comment-17120747
]
David Smiley commented on SOLR-13858:
-------------------------------------
I'm kinda scratching my head at this, but I don't pretend to have dug into the
underlying matters as much as you have.
Lets look at {{QParserPlugin}} for example -- the base class for all
QParserPlugins (query parsers, basically). This thing implements SolrInfoBean.
With the change here, it now indirectly, also implements SolrMetricProducer.
But QParserPlugin doesn't have metrics. Isn't it a bit of a sweeping change to
have all QParserPlugins suddenly implement this merely because they *could*
have metrics? Instead, couldn't a particularly expensive QParserPlugin
subclass (perhaps joins) opt-in to produce metrics while most of them don't?
Accidentally/unintentionally implementing a SolrMetricProducer also means
implementing AutoCloseable with a default impl, but the subclass might already
have a close method and it's easy to forget that your superclass needs to be
closed too. I wonder if metrics registration might be done with a weak
reference such that the something that registered metrics going out of scope
effectively auto-cleans up itself too. Just thinking out loud here.
As an aside, what do you think of SolrInfoBean? I look at it with it's few
basic metadata methods and question if it's worth having it exist. Solr could
still keep track of what plugins have been loaded via SolrResourceLoader, maybe
with a new "listener" pattern. The Listener would expose the expected Class
and thus the fundamental "type" of the plugin to thus group it appropriately
amongst similar plugins.
> Clean up SolrInfoBean / SolrMetricProducer API
> ----------------------------------------------
>
> Key: SOLR-13858
> URL: https://issues.apache.org/jira/browse/SOLR-13858
> Project: Solr
> Issue Type: Improvement
> Components: metrics
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-13858.patch
>
>
> For historical reasons both {{SolrInfoBean}} and {{SolrMetricProducer}}
> contain methods and constants / enums that deal with handling and reporting
> of metrics. In almost all cases implementations of {{SolrInfoBean}} also
> implement {{SolrMetricProducer}}.
> I propose to refactor this API so that {{SolrInfoBean}} simply extends
> {{SolrMetricProducer}}. This will reduce the API surface and eliminate
> multiple rote methods that subclasses must now implement.
> This is an incompatible API change so it's applicable only to version 9.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
