[ 
https://issues.apache.org/jira/browse/SOLR-4557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599541#comment-13599541
 ] 

Erick Erickson commented on SOLR-4557:
--------------------------------------

Right, thanks, I probably should have attached the jstack output too, sorry 
'bout that.

I'm about to write this off as a test artifact. The failing test relies on the 
test harness default constructors. I know that there are some places in the 
code that are sensitive to whether CoreContainer was loaded or the default 
fetched from the test harness. I'd really like to get those out of there, but 
don't have the time right now. I hate shipping code that has the equivalent of 
"if this is a test".....


Here's the failing test (part of it).:

    final CoreContainer cc = h.getCoreContainer();
    
    class TestThread extends Thread {
      @Override
      public void run() {
        cc.reload("collection1");
      }
    }

If I go ahead and create a real directory and actually load the  CoreContainer, 
then this exact test works like a champ. I'll attach a patch in a few minutes 
that has the re-written test. Unless people object, I'll check that in tomorrow 
and wash my hands of the problem.
                
> Fix broken CoreContainerTest.testReload
> ---------------------------------------
>
>                 Key: SOLR-4557
>                 URL: https://issues.apache.org/jira/browse/SOLR-4557
>             Project: Solr
>          Issue Type: Test
>    Affects Versions: 4.2, 5.0
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>         Attachments: SOLR-4557.patch, SOLR-4557_posthshutdown_stack.txt
>
>
> I was chasing down a test failure, and it turns out that 
> CoreContainerTest.testReload has only succeeded by chance. The test fires up 
> 4 threads that go out and reload the same core all at once. This caused me to 
> look at properly synchronizing reloading cores pursuant to SOLR-4196, on the 
> theory that we should serialize loading, unloading and reloading cores; we 
> shouldn't be doing _any_ of those operations from different threads on the 
> same core at the same time. It turns out that if you fire up multiple reloads 
> at once without serializing them, an error is thrown instead of proper 
> reloading occurring, and that's the only reason the test doesn't hang. The 
> stack trace of the exception is below for reference, but it doesn't with the 
> code I'll attach to this patch:
> [junit4:junit4]   2>  at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
> [junit4:junit4]   2>  at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427)
> [junit4:junit4]   2>  at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415)
> [junit4:junit4]   2>  at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:536)
> [junit4:junit4]   2>  at 
> org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:138)
> [junit4:junit4]   2>  at 
> org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:51)
> [junit4:junit4]   2>  at 
> org.apache.solr.core.RequestHandlers.register(RequestHandlers.java:106)
> [junit4:junit4]   2>  at 
> org.apache.solr.core.RequestHandlers.initHandlersFromConfig(RequestHandlers.java:157)
> [junit4:junit4]   2>  at 
> org.apache.solr.core.SolrCore.<init>(SolrCore.java:757)
> [junit4:junit4]   2>  at 
> org.apache.solr.core.SolrCore.reload(SolrCore.java:408)
> [junit4:junit4]   2>  at 
> org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1076)
> [junit4:junit4]   2>  at 
> org.apache.solr.core.TestCoreContainer$1TestThread.run(TestCoreContainer.java:90)

--
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]

Reply via email to