[jira] [Commented] (SOLR-13858) Clean up SolrInfoBean / SolrMetricProducer API

["David Smiley (Jira)" <ji...@apache.org>]

    [ 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: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org