Thanks for noticing this! I should have checked the tests better before I committed this! I also get random failures here running the test with -Dtests.iter: ant test -Dtestcase=TestSolrEntityProcessorUnit -Dtests.iter=1000
I'll also take a look at it. Martijn On 16 December 2011 13:51, Uwe Schindler <[email protected]> wrote: > Erick, as Hoss said, the test is buggy. It makes assumtions that the > EntrySet of a map is order. This is not the case, a Set by definition is > unsorted. So the test is buggy and luckily you investigated the bug. > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: [email protected] > > >> -----Original Message----- >> From: Erick Erickson [mailto:[email protected]] >> Sent: Friday, December 16, 2011 1:41 PM >> To: [email protected] >> Subject: Re: local 3x test failure >> >> See? After Uwe made me paranoid by finding the screw-up where I checked >> code in that didn't even compile under 1.5 I started getting more thorough > with >> using 1.5. Lucky me. >> >> So, can we stop developing 3.x sometime real soon now and make my life >> easier? <G> >> >> Anyway, I'll take care of this today. >> >> Erick >> >> On Thu, Dec 15, 2011 at 11:46 PM, Steven A Rowe <[email protected]> wrote: >> > Oh, and the reason Jenkins isn't seeing this failure is that it runs > branch_3x >> tests using Java 1.6, after first *compiling* with Java 1.5. >> > >> >> -----Original Message----- >> >> From: Steven A Rowe [mailto:[email protected]] >> >> Sent: Thursday, December 15, 2011 11:45 PM >> >> To: [email protected] >> >> Subject: RE: local 3x test failure >> >> >> >> FYI, I see this same failure when I run the branch_3x tests with Java >> >> 1.5, but not 1.6. >> >> >> >> > -----Original Message----- >> >> > From: Erick Erickson [mailto:[email protected]] >> >> > Sent: Thursday, December 15, 2011 9:52 PM >> >> > To: [email protected] >> >> > Subject: local 3x test failure >> >> > >> >> > I'm consistently getting the error below when running tests, >> >> > updated checkout of Solr 3x, no changes to the code. >> >> > >> >> > Note, in my case, it isn't necessary to specify the seed at all, >> >> > "ant test -Dtestcase=TestSolrEntityProcessorUnit" fails all by > itself. >> >> > >> >> > Looking at the test code, it *appears* to be an ordering problem. >> >> > This bit of code (lines 119+ >> >> > TestSolrEntityProcessorUnit.testMultiThread) >> >> > is throwing the error: >> >> > for (Entry<String,Object> entry : row.entrySet()) { >> >> > assertEquals(expectedDoc[i][0], entry.getKey()); >> >> > assertEquals(expectedDoc[i][1], entry.getValue()); >> >> > i++; >> >> > } >> >> > >> >> > All the values are there, just not ordered that way. If I change >> >> > the asserts to: >> >> > assertEquals(expectedDoc[(i+1)%2][0], entry.getKey()); >> >> > assertEquals(expectedDoc[(i+1)%2][1], entry.getValue()); >> >> > >> >> > it works just fine. I'm not in the least proposing this as a fix >> >> > for tolerably obvious reasons, but if someone wants to look at this >> >> > I figure it's good data to have. >> >> > >> >> > And I'm perplexed why this isn't apparently happening on the build >> >> > machine.... >> >> > >> >> > And it's late enough in the evening that I don't dare change the >> >> > code, especially for fear that this has something to do with my >> >> > environment..... >> >> > >> >> > Erick >> >> > >> >> > >> >> > Java version: >> >> > java version "1.5.0_30" >> >> > Java(TM) 2 Runtime Environment, Standard Edition (build >> >> > 1.5.0_30-b03-389-10M3527) >> >> > Java HotSpot(TM) Client VM (build 1.5.0_30-161, mixed mode, >> >> > sharing) >> >> > >> >> > [junit] ------------- Standard Error ----------------- >> >> > [junit] NOTE: reproduce with: ant test >> >> > -Dtestcase=TestSolrEntityProcessorUnit -Dtestmethod=testMultiThread >> >> > -Dtests.seed=7d8b82edcf5e7451:-3e7338fa530fae6d:-12dd2d3d55b3edde >> >> > -Dargs="-Dfile.encoding=MacRoman" >> >> > [junit] WARNING: test class left thread running: >> >> > Thread[pool-1-thread-1,5,main] >> >> > [junit] WARNING: test class left thread running: >> >> > Thread[pool-2-thread-1,5,main] >> >> > [junit] WARNING: test class left thread running: >> >> > Thread[pool-3-thread-1,5,main] >> >> > [junit] WARNING: test class left thread running: >> >> > Thread[pool-4-thread-1,5,main] >> >> > [junit] WARNING: test class left thread running: >> >> > Thread[pool-5-thread-1,5,main] >> >> > [junit] RESOURCE LEAK: test class left 5 thread(s) running >> >> > [junit] NOTE: test params are: locale=no, >> >> > timezone=Europe/Samara >> >> > [junit] NOTE: all tests run in this JVM: >> >> > [junit] [TestSolrEntityProcessorUnit] >> >> > [junit] NOTE: Mac OS X 10.6.8 i386/Apple Inc. 1.5.0_30 >> >> > (32-bit)/cpus=2,threads=1,free=509856,total=2031616 >> >> > [junit] ------------- ---------------- --------------- >> >> > [junit] Testcase: >> >> > >> >> testMultiThread(org.apache.solr.handler.dataimport.TestSolrEntityProc >> >> essor >> >> > Unit): FAILED >> >> > [junit] expected:<[id]> but was:<[description]> >> >> > [junit] junit.framework.AssertionFailedError: expected:<[id]> >> >> > but was:<[description]> >> >> > [junit] at >> >> > >> >> org.apache.solr.handler.dataimport.TestSolrEntityProcessorUnit.testMu >> >> ltiTh >> >> > read(TestSolrEntityProcessorUnit.java:120) >> >> > [junit] at >> >> > >> >> org.apache.lucene.util.LuceneTestCase$2$1.evaluate(LuceneTestCase.jav >> >> a:432 >> >> > ) >> >> > [junit] at >> >> > >> >> >> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner. >> >> > java:147) >> >> > [junit] at >> >> > >> >> >> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner. >> >> > java:50) >> >> > >> >> > ------------------------------------------------------------------- >> >> > -- To unsubscribe, e-mail: [email protected] For >> >> > additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] For additional >> commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Met vriendelijke groet, Martijn van Groningen --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
