Hi Gus, Glad you figured it out - sorry I didn't reply before! SolrCloudTestCase uses MiniSolrCloudCluster, which spins up several jetty nodes, each with its own CoreContainer. There was initially a lot of static configuration in there which needed to be removed to allow things like concurrent setup and teardown. If you're just testing something that needs a single container, you may find using SolrTestCaseJ4 is more useful, as it doesn't need to start a Jetty server with all the concomitant resource usage.
Alan Woodward www.flax.co.uk On 1 Mar 2016, at 22:27, Gus Heck wrote: > Ah figured it out, I had forgotten that when I started on this yesterday, > before I had a solid plan for what the test was going to look like I had > gratuitously stuck a 2 in for NUM_CORES and forgot all about it. So it seems > that More than one CoreContainer can happen within a JVM with this test > class. I imagine that this could expose any lurking funny business with > static variables if it exists :). Also worth noting that this test might lead > one into temptation too... making my variable static fixed my duplication > problem and made the test pass (but that made me itchy and I dug deeper... > luckily I figured out what was going on. Boy do I love folder level local > history :) ). > > -Gus > > On Tue, Mar 1, 2016 at 2:56 PM, Gus Heck <[email protected]> wrote: > I've been trying to write a unit test using the new SolrCloudTestCase class, > but I've discovered something surprising: It seems that when I create 2 > collections, they sometimes wind up in the same CoreContainer, and sometimes > in two separate CoreContainer objects... I had previously imagined that > CoreContainer was one per java process (per Node). Was I wrong? Could this be > a bug? (and of course then the question is if it's a bug in the > SolrCloudTestCase, or in the base solr classes. > > -Gus > > > > > > -- > http://www.the111shift.com
