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

Reply via email to