[jira] [Commented] (SOLR-5095) SolrCore.infoRegistry needs overhauled with some form of "namespacing"

["Hoss Man (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13724661#comment-13724661 ] 

Hoss Man commented on SOLR-5095:
--------------------------------


For 5.0, I think we should completley overhaul the way the infoRegistery works...

 * Replace the simple {{Map<String, SolrInfoMBean>}} with something utilizing the "type" of plugin as a namespace or parent hierarchy (ie: RequestHandler, SearchComponent, QParserPlugin, etc...)
 * replace all of hte existing JMX ObjectName's used to register MBeans so the JMX hierarchy matches the new hierarchical orgainized by plugin "type".
 * update /admin/mbeans so that in addition to the current "cat" and "key" lookups you can also browser MBeans by their plugin "type"
 * update the UI to show the list of Mbeans organized by "type" instead of by "cat"
 * along the way, make sure we cleanup things like SOLR-3774


For 4.x, i think we should leave this alone -- any kind of meaningful fix I can imagine would require changing the names used to register things in JMX, and that seems like something too significant to change in a minor release give how it will affect existing users who monitor with JMX.  For consistency, we could concievably just fix the bug in JmxMonitordMap.put() so that JMX accurately reflects only the items in the infoRegistry -- but that wouldn't relaly help anyone, it ould just take potentially useful data away from JMX users.

                
> SolrCore.infoRegistry needs overhauled with some form of "namespacing"
> ----------------------------------------------------------------------
>
>                 Key: SOLR-5095
>                 URL: https://issues.apache.org/jira/browse/SOLR-5095
>             Project: Solr
>          Issue Type: Bug
>            Reporter: Hoss Man
>         Attachments: SOLR-5095_bug_demo.patch
>
>
> While investigating SOLR-3616, I realized the failure i was seeing didn't seem to be related to the initial report of that bug, and instead seemed to be due to an obvious and fundemental limitation in the way SolrCore keeps track of "plugins" using the infoRegistry: It's just a {{Map<String, SolrInfoMBean>}} keyed off of the name of the plugin, but there is not "namespacing" used in the infoRegistry, so two completley different types of plugins with the same name will overwrite each other.
> When looking at data using something like /admin/mbeans, this manifests itself solely as missing objects: last one .put() into the infoRegistry "wins" -- using JMX, both objects are actually visible because of how JMX ObjectNames are built arround a set of key=val pairs, and a bug in how JmxMonitorMap unregisters existing MBeans when .put() is called on a key it already knows about (the unregister call is made using an ObjectName built using the infoBean passed to the put() call -- if infoBean.getName() is not exactly the same as the previous infoBean put() with the same key, then the MbeanServer will continue to know about both of them)

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