[
https://issues.apache.org/jira/browse/SOLR-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756711#action_12756711
]
Hoss Man commented on SOLR-1427:
--------------------------------
Comments from email thread...
{quote}
I haven't tried to reproduce the problem, and i don't even have a concrete
theory as to what the problem is ... but i did want to point out something
that smells fishy...
looking over the patch in SOLR-1427, i notice that the patch adds new code
so that SolrResourceLoader adds everything it instantiates to the registry
map -- but there are no lines in that patch removing any code that was
already adding stuff to the infoRegistry ... which means any bean
types that were already getting instantiated by the ResourceLoader, and
explicitly
added to hte registry are probably now getting added to the registry twice
... for a normal Map that's not a big deal, but perhaps the JMX backed map
has some problems with that? (it's not likely something that we ever
tested extensively)
Alternately: maybe the problem isn't with adding to the JMX backed map
twice ... maybe the issue is what state the beans are in each time we add
them to the map ... the first time requesthandlers are added to the
infoRegistry it's prior to the inform(SolrCore) call so they havne't been
fully initalized yet -- but the way SOlrResourceLoader adds them now (the
second time) is *after* inform(SolrCore) has been called and in between
the creation/countDown of the CountDownLatch for the searchExecutor ...
...hmmm, actually this starting to sound like a concrete theory,
ReplicationHandler.getStatistics has very different behavior before/after
inform(SolrCore) has been called....
Maybe moving the resourceLoader.inform(infoRegistry) call PRIOR to
resourceLoader.inform( this ) *or* AFTER latch.countDown() would solve
this problem?
{quote}
followup comment...
{quote}
If this really is the problem, then a more general purpose solution to
future proof us against similar problems down the road would probably be
to get rid of the current "if (config.jmxConfig.enabled)" logic for
initializing SolrCore.infoRegistry, and instead us something like...
infoRegistry = new ConcurrentHashMap<String, SolrInfoMBean>();
...
// do all initialization, add things to infoRegistry as needed
...
// done with all initilation, core and all MBeans are fully functional
if (config.jmxConfig.enabled) {
Map tmp = infoRegistry;
infoRegistry = new JmxMonitoredMap<String, SolrInfoMBean>(name,
config.jmxConfig);
infoRegistry.putAll(tmp);
} else {
log.info("JMX monitoring not detected for core: " + name);
}
...that way we wouldn't have to worry about any other type of resource
contention that might happen from the JMX monitor wanting ot get info from
the MBeans as soon as they are added to the registry.
{quote}
> SearchComponents aren't listed on registry.jsp
> ----------------------------------------------
>
> Key: SOLR-1427
> URL: https://issues.apache.org/jira/browse/SOLR-1427
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Assignee: Grant Ingersoll
> Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1427.patch, SOLR-1427.patch
>
>
> SearchComponent implements SolrInfoMBean using getCategory() of "OTHER" but
> they aren't listed on the registry.jsp display of loaded plugins.
> This may be a one-of-glitch because of the way SearchComponents get loaded,
> or it may indicate some other problem with the infoRegistry.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
