: Interesting... I still haven't been able to reproduce a hang with : either jetty or tomcat. : I enabled replication and JMX... still nothing.
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? -Hoss
