lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Updated] (SOLR-5095) SolrCore.infoRegistry needs overhauled with some form of "namespacing"
Date Wed, 31 Jul 2013 00:29:51 GMT


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
 * in the configs used by the test: there a "dismax" SearchHandler instance declared, in addition
to the out of the box default "dismax" QParser

  [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(
   [junit4]    > 	at

> SolrCore.infoRegistry needs overhauled with some form of "namespacing"
> ----------------------------------------------------------------------
>                 Key: SOLR-5095
>                 URL:
>             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

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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message