[
https://issues.apache.org/jira/browse/SOLR-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13699565#comment-13699565
]
Erik Hatcher edited comment on SOLR-4991 at 7/3/13 11:07 PM:
-------------------------------------------------------------
bq. Why do we need to see these?
For apps to be able to see what query parsers are available.
bq. Any builtin plugins we should be able to just rely on them being there and
this just adds more noise and startup costs. Perhaps instead we need a way (if
we don't have one already) for anyone (i.e. any kind of plugin) to add
externally visible statistics?
It's not really about the statistics for my initial use case - it's about an
app pointed at a Solr and being able to discern what query parsers are
available.
The main point here, forgetting about numRequests, is simply to have a way for
plugins to be discoverable from the outside. This fits in the longer term goal
to RESTify all of these things, at least in my opinion, but this is an easy and
useful capability in the mean time.
bq. Just wondering why would a query parser (or a highlighter for that matter)
need numRequests?
Good question, I wondered that myself when I saw HighlightingPluginBase do
this. But I can imagine it'd be useful to see which query parser(s) are being
used. One might even want to monitor for inadvertent, or even suspicious, uses
of other query parsers.
was (Author: ehatcher):
bq. Why do we need to see these?
For apps to be able to see what query parsers are available.
bq. Any builtin plugins we should be able to just rely on them being there and
this just adds more noise and startup costs. Perhaps instead we need a way (if
we don't have one already) for anyone (i.e. any kind of plugin) to add
externally visible statistics?
It's not really about the statistics for my initial use case - it's about an
app pointed at a Solr and being able to discern what query parsers are
available.
The main point here, forgetting about numRequests, is simply to have a way for
plugins to be discoverable from the outside. This fits in the longer term goal
to RESTify all of these things, at least in my opinion, but this is an easy and
useful capability in the mean time.
bq. Just wondering why would a query parser (or a highlighter for that matter)
need numRequests?
Good question, I wondered that myself when I saw HighlightingPluginBase do
this. But I can imagine it'd be useful to see how which query parser(s) are
being used.
> Register QParserPlugin's as SolrInfoMBean's, allowing them to be visible
> externally like other plugins
> ------------------------------------------------------------------------------------------------------
>
> Key: SOLR-4991
> URL: https://issues.apache.org/jira/browse/SOLR-4991
> Project: Solr
> Issue Type: Improvement
> Components: query parsers
> Reporter: Erik Hatcher
> Fix For: 5.0, 4.4
>
> Attachments: SOLR-4991.patch, SOLR-4991.patch
>
>
> QParserPlugins currently cannot be seen externally as official plugins*.
> Let's register them as SolrInfoMBeans so they can be seen remotely.
> * Yes, solrconfig.xml itself could be retrieved and parsed, but many other
> similar plugins are available as MBeans and so should be query parsers.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
