[
https://issues.apache.org/jira/browse/SOLR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-5095:
---------------------------
Attachment: SOLR-5095_bug_demo.patch
SOLR-5095_bug_demo.patch is a trivial test patch demonstrating the discrepency
between the infoRegistry contents and the JMX contents ... the off by 2 error
is because...
* out of hte box defaults defin a "query" QParser (NestedQParserPlugin) and a
"query" SearchComponent (QueryComponent).
* in the configs used by the test: there a "dismax" SearchHandler instance
declared, in addition to the out of the box default "dismax" QParser
{noformat}
[junit4] FAILURE 0.04s | TestJmxIntegration.testInfoRegistryVsMbeanServer <<<
[junit4] > Throwable #1: java.lang.AssertionError: regSize != numMbeans
expected:<79> but was:<81>
[junit4] > at
__randomizedtesting.SeedInfo.seed([CF457CF6E471C68:3997F649BAD78365]:0)
[junit4] > at
org.apache.solr.core.TestJmxIntegration.testInfoRegistryVsMbeanServer(TestJmxIntegration.java:86)
[junit4] > at java.lang.Thread.run(Thread.java:724)
{noformat}
> 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: [email protected]
For additional commands, e-mail: [email protected]
