Erick Erickson
2011-12-16, 02:51
Chris Hostetter
2011-12-16, 03:05
Erick Erickson
2011-12-16, 03:12
Steven A Rowe
2011-12-16, 04:44
Steven A Rowe
2011-12-16, 04:46
Erick Erickson
2011-12-16, 12:41
Uwe Schindler
2011-12-16, 12:51
Martijn v Groningen
2011-12-16, 14:11
Erick Erickson
2011-12-16, 14:55
Martijn v Groningen
2011-12-16, 15:03
Erick Erickson
2011-12-16, 15:24
Martijn v Groningen
2011-12-16, 15:40
Erick Erickson
2011-12-16, 16:01
Martijn v Groningen
2011-12-16, 17:05
-
local 3x test failureErick Erickson 2011-12-16, 02:51
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.TestSolrEntityProcessorUnit): FAILED
[junit] expected:<[id]> but was:<[description]>
[junit] junit.framework.AssertionFailedError: expected:<[id]> but
was:<[description]>
[junit] at
org.apache.solr.handler.dataimport.TestSolrEntityProcessorUnit.testMultiThread(TestSolrEntityProcessorUnit.java:120)
[junit] at
org.apache.lucene.util.LuceneTestCase$2$1.evaluate(LuceneTestCase.java:432)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
---------------------------------------------------------------------
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.TestSolrEntityProcessorUnit): FAILED
[junit] expected:<[id]> but was:<[description]>
[junit] junit.framework.AssertionFailedError: expected:<[id]> but
was:<[description]>
[junit] at
org.apache.solr.handler.dataimport.TestSolrEntityProcessorUnit.testMultiThread(TestSolrEntityProcessorUnit.java:120)
[junit] at
org.apache.lucene.util.LuceneTestCase$2$1.evaluate(LuceneTestCase.java:432)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:147)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
---------------------------------------------------------------------
-
Re: local 3x test failureChris Hostetter 2011-12-16, 03:05
: 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.
i don't see a failure, but skimming the code it looks fairly broken to
me...
: for (Entry<String,Object> entry : row.entrySet()) {
: assertEquals(expectedDoc[i][0], entry.getKey());
: assertEquals(expectedDoc[i][1], entry.getValue());
: i++;
: }
...those lines are assuming that row.entrySet will return something that
has a predictible iteration order, but row is a Map of unknown creation
(returned by the entityProcessor) ... so unless the entityProcessor is
explicitly defined as returning something like SortedMap (which isn't
suggested anywhere in this test) the test is making a really bad
assumption.
it looks like the "expectedDoc" data structure should be some sort of map
that is then compared to row (possibly by just doing and assertEquals on
the respective entrySets)
-Hoss
---------------------------------------------------------------------
-
Re: local 3x test failureErick Erickson 2011-12-16, 03:12
Chris:
Thanks, that's the reassurance I was looking for. I'll fix this
up tomorrow so it isn't order sensitive. But I didn't want to just
go fix this up without some clue whether the ordering was
supposed to matter (or not).
And it's just too darn late to bother. This stupid thing caused
me enough frustration thinking my changes for SOLR-2971
were responsible that I didn't trust myself to make that call
tonight.....
Erick
On Thu, Dec 15, 2011 at 10:05 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
>
> : 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.
>
> i don't see a failure, but skimming the code it looks fairly broken to
> me...
>
> : for (Entry<String,Object> entry : row.entrySet()) {
> : assertEquals(expectedDoc[i][0], entry.getKey());
> : assertEquals(expectedDoc[i][1], entry.getValue());
> : i++;
> : }
>
> ...those lines are assuming that row.entrySet will return something that
> has a predictible iteration order, but row is a Map of unknown creation
> (returned by the entityProcessor) ... so unless the entityProcessor is
> explicitly defined as returning something like SortedMap (which isn't
> suggested anywhere in this test) the test is making a really bad
> assumption.
>
> it looks like the "expectedDoc" data structure should be some sort of map
> that is then compared to row (possibly by just doing and assertEquals on
> the respective entrySets)
>
>
> -Hoss
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
Thanks, that's the reassurance I was looking for. I'll fix this
up tomorrow so it isn't order sensitive. But I didn't want to just
go fix this up without some clue whether the ordering was
supposed to matter (or not).
And it's just too darn late to bother. This stupid thing caused
me enough frustration thinking my changes for SOLR-2971
were responsible that I didn't trust myself to make that call
tonight.....
Erick
On Thu, Dec 15, 2011 at 10:05 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
>
> : 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.
>
> i don't see a failure, but skimming the code it looks fairly broken to
> me...
>
> : for (Entry<String,Object> entry : row.entrySet()) {
> : assertEquals(expectedDoc[i][0], entry.getKey());
> : assertEquals(expectedDoc[i][1], entry.getValue());
> : i++;
> : }
>
> ...those lines are assuming that row.entrySet will return something that
> has a predictible iteration order, but row is a Map of unknown creation
> (returned by the entityProcessor) ... so unless the entityProcessor is
> explicitly defined as returning something like SortedMap (which isn't
> suggested anywhere in this test) the test is making a really bad
> assumption.
>
> it looks like the "expectedDoc" data structure should be some sort of map
> that is then compared to row (possibly by just doing and assertEquals on
> the respective entrySets)
>
>
> -Hoss
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
-
RE: local 3x test failureSteven A Rowe 2011-12-16, 04:44
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.TestSolrEntityProcessor
> 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.testMultiTh
> read(TestSolrEntityProcessorUnit.java:120)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$2$1.evaluate(LuceneTestCase.java: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]
> -----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.TestSolrEntityProcessor
> 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.testMultiTh
> read(TestSolrEntityProcessorUnit.java:120)
> [junit] at
> org.apache.lucene.util.LuceneTestCase$2$1.evaluate(LuceneTestCase.java: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]
-
RE: local 3x test failureSteven A Rowe 2011-12-16, 04:46
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.TestSolrEntityProcessor
> > 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.testMultiTh
> > read(TestSolrEntityProcessorUnit.java:120)
> > [junit] at
> >
> org.apache.lucene.util.LuceneTestCase$2$1.evaluate(LuceneTestCase.java:432
> > )
> > [junit] at
> >
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.
> > java:147)
> -----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.TestSolrEntityProcessor
> > 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.testMultiTh
> > read(TestSolrEntityProcessorUnit.java:120)
> > [junit] at
> >
> org.apache.lucene.util.LuceneTestCase$2$1.evaluate(LuceneTestCase.java:432
> > )
> > [junit] at
> >
> org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.
> > java:147)
-
Re: local 3x test failureErick Erickson 2011-12-16, 12:41
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.TestSolrEntityProcessor
>> > Unit): FAILED
>> > [junit] expected:<[id]> but was:<[description]>
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.TestSolrEntityProcessor
>> > Unit): FAILED
>> > [junit] expected:<[id]> but was:<[description]>
-
RE: local 3x test failureUwe Schindler 2011-12-16, 12:51
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:
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:
-
Re: local 3x test failureMartijn v Groningen 2011-12-16, 14:11
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"
Met vriendelijke groet,
Martijn van Groningen
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"
Met vriendelijke groet,
Martijn van Groningen
-
Re: local 3x test failureErick Erickson 2011-12-16, 14:55
@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
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
-
Re: local 3x test failureMartijn v Groningen 2011-12-16, 15:03
@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
Met vriendelijke groet,
Martijn van Groningen
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
Met vriendelijke groet,
Martijn van Groningen
-
Re: local 3x test failureErick Erickson 2011-12-16, 15:24
@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
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
-
Re: local 3x test failureMartijn v Groningen 2011-12-16, 15:40
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:
Met vriendelijke groet,
Martijn van Groningen
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:
Met vriendelijke groet,
Martijn van Groningen
-
Re: local 3x test failureErick Erickson 2011-12-16, 16:01
Martijn:
I didn't mean to unilaterally shove it over onto your plate, I was
just making sure we wouldn't each think the other was going to check
in the code and drop it on the floor. And since you had additional
improvements you wanted to make....
Erick
On Fri, Dec 16, 2011 at 10:40 AM, Martijn v Groningen
<[EMAIL PROTECTED]> wrote:
> 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.
I didn't mean to unilaterally shove it over onto your plate, I was
just making sure we wouldn't each think the other was going to check
in the code and drop it on the floor. And since you had additional
improvements you wanted to make....
Erick
On Fri, Dec 16, 2011 at 10:40 AM, Martijn v Groningen
<[EMAIL PROTECTED]> wrote:
> 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.
-
Re: local 3x test failureMartijn v Groningen 2011-12-16, 17:05
No worries. This test is difficult to understand and improving that is
also part of fixing the test.
Martijn
On 16 December 2011 17:01, Erick Erickson <[EMAIL PROTECTED]> wrote:
> Martijn:
>
> I didn't mean to unilaterally shove it over onto your plate, I was
> just making sure we wouldn't each think the other was going to check
> in the code and drop it on the floor. And since you had additional
> improvements you wanted to make....
>
> Erick
>
>
> On Fri, Dec 16, 2011 at 10:40 AM, Martijn v Groningen
> <[EMAIL PROTECTED]> wrote:
>> 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-----
>>>>>>>> >>
Met vriendelijke groet,
Martijn van Groningen
also part of fixing the test.
Martijn
On 16 December 2011 17:01, Erick Erickson <[EMAIL PROTECTED]> wrote:
> Martijn:
>
> I didn't mean to unilaterally shove it over onto your plate, I was
> just making sure we wouldn't each think the other was going to check
> in the code and drop it on the floor. And since you had additional
> improvements you wanted to make....
>
> Erick
>
>
> On Fri, Dec 16, 2011 at 10:40 AM, Martijn v Groningen
> <[EMAIL PROTECTED]> wrote:
>> 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-----
>>>>>>>> >>
Met vriendelijke groet,
Martijn van Groningen
