Sure no problem. I'll add the changes to SOLR-2975 and commit it from there.
Martijn On 16 December 2011 16:24, Erick Erickson <[email protected]> wrote: > @Martijn > I'm so glad to hear that it confuses you too, it made my eyes cross. > > So I'll leave it entirely up to you, right? > > Erick > > On Fri, Dec 16, 2011 at 10:03 AM, Martijn v Groningen > <[email protected]> wrote: >> @Erick >> Cool. This test confuses me a bit with the String[][][] that >> represents a document. I'm rewriting that to use SolrTestCaseJ4.Doc >> class, which I think will make the test more readable. >> >> On 16 December 2011 15:55, Erick Erickson <[email protected]> wrote: >>> @Uwe >>> just teasing, but I *do* test with Java 1.5 thanks to you! >>> >>> @Martijn >>> I've got fixes ready to check in, just running through full test now. >>> I'll attach the current version to the bug (SOLR-2975) for your >>> perusal. I tried changing things to use List<Map<String, Object>> but >>> couldn't get that to work with the multivalued test so put in a method >>> to compare things as maps. You'll see in the patch..... >>> >>> Erick >>> >>> On Fri, Dec 16, 2011 at 9:11 AM, Martijn v Groningen >>> <[email protected]> wrote: >>>> 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] >>>> >>> >>> --------------------------------------------------------------------- >>> 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] >> > > --------------------------------------------------------------------- > 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]
