[jira] [Updated] (SOLR-5095) SolrCore.infoRegistry needs overhauled with some form of "namespacing"
[
https://issues.apache.org/jira/browse/SOLR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5095:
---
Attachment: SOLR-5095.patch
1. Made map key as JMX canonical name that correspond to registered mbean and
unique
2. Overriden Map.get in order to translate existing key to JMX canonical name
3. Changed unregister method: removed unused InfoMBean parameter, changed
unregister to work on canonical name
4. JMX names reminded unchanged and backward compatible
> 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.patch, SOLR-5095_bug_demo.patch
>
>
> While investigating SOLR-3616 / SOLR-2715, 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}} 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 was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5095) SolrCore.infoRegistry needs overhauled with some form of "namespacing"
[
https://issues.apache.org/jira/browse/SOLR-5095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-5095:
---
Description:
While investigating SOLR-3616 / SOLR-2715, 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}} 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)
was:
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}}
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)
> 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 / SOLR-2715, 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}} 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5095) SolrCore.infoRegistry needs overhauled with some form of "namespacing"
[
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 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
