Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

2012-06-01 Thread Michael McCandless 
On Thu, May 31, 2012 at 8:05 PM, Robert Muir rcm...@gmail.com wrote:
 On Thu, May 31, 2012 at 5:51 PM, Michael McCandless
 luc...@mikemccandless.com wrote:
 I think the best option is to ignore the OOME from this test case...?

 Mike McCandless


 I think thats fine for now, but I'm not convinced there is no problem
 at all. However, its not obvious the problem is us, either.

 Its easy to see this OOM is related to G1 garbage collector.

 This test has failed 3 times in the past couple days (before it never
 failed: i suspect packed ints changes sent it over the edge).

 https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2707/
 https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2719/
 https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2723/

 All 3 cases are java 7, and all 3 cases uses -XX:+UseG1GC. (Uwe turned
 on GC randomization at lucene revolution)

Aha!  Nice sleuthing :)

So maybe this means G1 isn't as good when heap is limited...

Can we somehow detect / pass property to the JVM when G1 is in use?
Then we can scope down the ignore OOME I committed to only when G1
is in use...

Mike McCandless

http://blog.mikemccandless.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

2012-05-31 Thread Apache Jenkins Server 
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2723/

1 tests failed.
REGRESSION:  org.apache.lucene.util.packed.TestPackedInts.testIntOverflow

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([44E7903FBFDCF43:A1996D29E3A73716]:0)
at 
org.apache.lucene.util.packed.Packed64SingleBlock.init(Packed64SingleBlock.java:115)
at 
org.apache.lucene.util.packed.Packed64SingleBlock$Packed64SingleBlock3.init(Packed64SingleBlock.java:315)
at 
org.apache.lucene.util.packed.Packed64SingleBlock.create(Packed64SingleBlock.java:64)
at 
org.apache.lucene.util.packed.TestPackedInts.testIntOverflow(TestPackedInts.java:303)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:814)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:889)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:821)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:669)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:695)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:734)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:745)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)




Build Log:
${BUILD_LOG_REGEX,regex=(?x:
# Compilation failures
(?:[^\\r\\n]*\\[javac\\].*\\r?\\n)*[^\\r\\n]*\\[javac\\]\\s*[1-9]\\d*\\s*error.*\\r?\\n
# Test failures
|[^\\r\\n]*\\[junit4\\]\\s*Suite:.*[\\r\\n]+[^\\r\\n]*\\[junit4\\]\\s*(?!Completed)(?!IGNOR)\\S(?s:.*?)\\s*FAILURES!
# License problems
|[^\\r\\n]*rat-sources:\\s+\\[echo\\].*(?:\\r?\\n[^\\r\\n]*\\[echo\\].*)*\\s*[1-9]\\d*\\s+Unknown\\s+Licenses.*\\r?\\n(?:[^\\r\\n]*\\[echo\\].*\\r?\\n)*
# Javadocs warnings
|(?:[^\\r\\n]*\\[javadoc\\].*\\r?\\n)*[^\\r\\n]*\\[javadoc\\]\\s*[1-9]\\d*\\s+warnings.*\\r?\\n
# Other javadocs problems (broken links and missing javadocs)
|[^\\r\\n]*javadocs-lint:.*\\r?\\n(?:[^\\r\\n]*\\[echo\\].*\\r?\\n)*
# Third-party dependency license/notice problems
|[^\\r\\n]*validate:.*\\r?\\n[^\\r\\n]*\\[echo\\].*\\r?\\n(?:[^\\r\\n]*\\[licenses\\].*\\r?\\n)*[^\\r\\n]*\\[licenses\\].*[1-9]\\d*\\s+error.*\\r?\\n
# Jenkins problems
|[^\\r\\n]*FATAL:(?s:.*)
)}


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

2012-05-31 Thread Steven A Rowe 
Hmm, looks like spreading the BUILD_LOG_REGEX across multiple lines caused it 
not to be recognized.

Jenkins's email templating functionality is provided by the Jenkins Email 
Extension Plugin (email-ext) 
https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin.

The token parsing is done by 
hudson.plugins.emailext.plugins.ContentBuilder.Tokenizer: 
https://github.com/jenkinsci/email-ext-plugin/blob/master/src/main/java/hudson/plugins/emailext/plugins/ContentBuilder.java#L134

Here's the relevant argument-value regex (used to parse the value of the 
regex argument to the BUILD_LOG_REGEX token): 

private static final String stringRegex = 
\([^\\\r\\n]|(.))*\;

So I *think* if I put a backslash (escaped with another backslash) at the end 
of each line, I can keep the multiple lines (and comments).  I'll give it a try.

Steve

-Original Message-
From: Apache Jenkins Server [mailto:jenk...@builds.apache.org] 
Sent: Thursday, May 31, 2012 2:55 PM
To: dev@lucene.apache.org
Subject: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2723/

1 tests failed.
REGRESSION:  org.apache.lucene.util.packed.TestPackedInts.testIntOverflow

Error Message:
Java heap space

Stack Trace:
java.lang.OutOfMemoryError: Java heap space
at 
__randomizedtesting.SeedInfo.seed([44E7903FBFDCF43:A1996D29E3A73716]:0)
at 
org.apache.lucene.util.packed.Packed64SingleBlock.init(Packed64SingleBlock.java:115)
at 
org.apache.lucene.util.packed.Packed64SingleBlock$Packed64SingleBlock3.init(Packed64SingleBlock.java:315)
at 
org.apache.lucene.util.packed.Packed64SingleBlock.create(Packed64SingleBlock.java:64)
at 
org.apache.lucene.util.packed.TestPackedInts.testIntOverflow(TestPackedInts.java:303)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:814)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:889)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:821)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:669)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:695)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:734)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:745)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)




Build Log:
${BUILD_LOG_REGEX,regex=(?x:
# Compilation failures
(?:[^\\r\\n]*\\[javac\\].*\\r?\\n)*[^\\r\\n]*\\[javac\\]\\s*[1-9]\\d*\\s*error.*\\r?\\n
# Test failures
|[^\\r\\n]*\\[junit4\\]\\s*Suite:.*[\\r\\n]+[^\\r\\n]*\\[junit4\\]\\s*(?!Completed)(?!IGNOR)\\S

Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

2012-05-31 Thread Michael McCandless 
This test intentionally allocates ~256 MB packed ints ... the seed
doesn't fail in isolation, but I think the test fails if it's run with
other tests that leave too much uncollectible stuff allocated in the
heap ...

Can we somehow mark that a test should be run in isolation (it's own
new JVM)...?

Another option ... would be to ignore the OOME ... but the risk there
is we suppress a real OOME from a sudden bug in the packed ints.
Though it's unlikely such a breakage would escape our usages of packed
ints... so maybe it's fine.

Mike McCandless

http://blog.mikemccandless.com


On Thu, May 31, 2012 at 2:54 PM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
 Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2723/

 1 tests failed.
 REGRESSION:  org.apache.lucene.util.packed.TestPackedInts.testIntOverflow

 Error Message:
 Java heap space

 Stack Trace:
 java.lang.OutOfMemoryError: Java heap space
        at 
 __randomizedtesting.SeedInfo.seed([44E7903FBFDCF43:A1996D29E3A73716]:0)
        at 
 org.apache.lucene.util.packed.Packed64SingleBlock.init(Packed64SingleBlock.java:115)
        at 
 org.apache.lucene.util.packed.Packed64SingleBlock$Packed64SingleBlock3.init(Packed64SingleBlock.java:315)
        at 
 org.apache.lucene.util.packed.Packed64SingleBlock.create(Packed64SingleBlock.java:64)
        at 
 org.apache.lucene.util.packed.TestPackedInts.testIntOverflow(TestPackedInts.java:303)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:601)
        at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
        at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
        at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:814)
        at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:875)
        at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:889)
        at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
        at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
        at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
        at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
        at 
 org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
        at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
        at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
        at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:821)
        at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
        at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:669)
        at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:695)
        at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:734)
        at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:745)
        at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
        at 
 org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
        at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
        at 
 org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
        at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
        at 
 org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)




 Build Log:
 ${BUILD_LOG_REGEX,regex=(?x:
 # Compilation failures
 (?:[^\\r\\n]*\\[javac\\].*\\r?\\n)*[^\\r\\n]*\\[javac\\]\\s*[1-9]\\d*\\s*error.*\\r?\\n
 # Test failures
 |[^\\r\\n]*\\[junit4\\]\\s*Suite:.*[\\r\\n]+[^\\r\\n]*\\[junit4\\]\\s*(?!Completed)(?!IGNOR)\\S(?s:.*?)\\s*FAILURES!
 # License problems
 |[^\\r\\n]*rat-sources:\\s+\\[echo\\].*(?:\\r?\\n[^\\r\\n]*\\[echo\\].*)*\\s*[1-9]\\d*\\s+Unknown\\s+Licenses.*\\r?\\n(?:[^\\r\\n]*\\[echo\\].*\\r?\\n)*
 # Javadocs warnings
 |(?:[^\\r\\n]*\\[javadoc\\].*\\r?\\n)*[^\\r\\n]*\\[javadoc\\]\\s*[1-9]\\d*\\s+warnings.*\\r?\\n
 # Other javadocs problems (broken links and missing javadocs)

Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

2012-05-31 Thread Dawid Weiss 
 This test intentionally allocates ~256 MB packed ints ... the seed
 doesn't fail in isolation, but I think the test fails if it's run with
 other tests that leave too much uncollectible stuff allocated in the
 heap ...

It doesn't need to be hard refs. With parallel garbage collectors
(with various staged memory pools) and fast allocation rate a thread
may fail with an OOM even if there is theoretically enough space for a
new allocated block. Running with SerialGC typically fixes the problem
but then -- this isn't realistic :)

 Can we somehow mark that a test should be run in isolation (it's own
 new JVM)...?

Technically this is possible I think (can't tell how large refactoring
it woudl be). But something in me objects to this idea. On the one
hand this is ideal test isolation; on the other hand I bet with time
all tests would just require a forked VM because it's simpler this
way. Good tests should clean up after themselves. I'm idealistic but
I believe tests should be fixed if they don't follow this rule.

 Another option ... would be to ignore the OOME ... but the risk there
 is we suppress a real OOME from a sudden bug in the packed ints.
 Though it's unlikely such a breakage would escape our usages of packed
 ints... so maybe it's fine.

How close are we to the memory limit if run in isolation (as a
stand-alone test case)? We can probably measure this by allocating a
byte[] before the test and doing binary search on its size depending
on if it OOMs or not? Maybe it's just really close to the memory
limit?

Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

2012-05-31 Thread Michael McCandless 
On Thu, May 31, 2012 at 5:16 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
 This test intentionally allocates ~256 MB packed ints ... the seed
 doesn't fail in isolation, but I think the test fails if it's run with
 other tests that leave too much uncollectible stuff allocated in the
 heap ...

 It doesn't need to be hard refs. With parallel garbage collectors
 (with various staged memory pools) and fast allocation rate a thread
 may fail with an OOM even if there is theoretically enough space for a
 new allocated block. Running with SerialGC typically fixes the problem
 but then -- this isn't realistic :)

Got it.

 Can we somehow mark that a test should be run in isolation (it's own
 new JVM)...?

 Technically this is possible I think (can't tell how large refactoring
 it woudl be). But something in me objects to this idea. On the one
 hand this is ideal test isolation; on the other hand I bet with time
 all tests would just require a forked VM because it's simpler this
 way. Good tests should clean up after themselves. I'm idealistic but
 I believe tests should be fixed if they don't follow this rule.

Yeah I hear you... hmm do we forcefully clear the FieldCache after
tests...?  Though, in theory once the AtomicReader is collectible the
FC's entries should be too...

 Another option ... would be to ignore the OOME ... but the risk there
 is we suppress a real OOME from a sudden bug in the packed ints.
 Though it's unlikely such a breakage would escape our usages of packed
 ints... so maybe it's fine.

 How close are we to the memory limit if run in isolation (as a
 stand-alone test case)? We can probably measure this by allocating a
 byte[] before the test and doing binary search on its size depending
 on if it OOMs or not? Maybe it's just really close to the memory
 limit?

OK I did that: if I alloc 68 MB byte[] up front we OOME, but 67 MB
byte[] and the test passes (run in isolation).

That's closer than I expected: the max long[] we alloc in the test is
273 MB.  So 512 - 273 - 68 = 171 MB unexplained hmm I think this
is because large arrays are alloc'd directly from the old generation:


http://stackoverflow.com/questions/9738911/javas-serial-garbage-collector-performing-far-better-than-other-garbage-collect

When I run with -XX:NewRatio=10 then I can pre-alloc 191 MB byte[] and
the test still passes ...

I think the best option is to ignore the OOME from this test case...?

Mike McCandless

http://blog.mikemccandless.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

2012-05-31 Thread Robert Muir 
On Thu, May 31, 2012 at 5:51 PM, Michael McCandless
luc...@mikemccandless.com wrote:
 I think the best option is to ignore the OOME from this test case...?

 Mike McCandless


I think thats fine for now, but I'm not convinced there is no problem
at all. However, its not obvious the problem is us, either.

Its easy to see this OOM is related to G1 garbage collector.

This test has failed 3 times in the past couple days (before it never
failed: i suspect packed ints changes sent it over the edge).

https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2707/
https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2719/
https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2723/

All 3 cases are java 7, and all 3 cases uses -XX:+UseG1GC. (Uwe turned
on GC randomization at lucene revolution)


-- 
lucidimagination.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure

2012-05-31 Thread Dawid Weiss 
Aaahhh... I thought G1 will start causing issues at some point. Good
catch, Robert.

Dawid

On Fri, Jun 1, 2012 at 2:05 AM, Robert Muir rcm...@gmail.com wrote:
 On Thu, May 31, 2012 at 5:51 PM, Michael McCandless
 luc...@mikemccandless.com wrote:
 I think the best option is to ignore the OOME from this test case...?

 Mike McCandless


 I think thats fine for now, but I'm not convinced there is no problem
 at all. However, its not obvious the problem is us, either.

 Its easy to see this OOM is related to G1 garbage collector.

 This test has failed 3 times in the past couple days (before it never
 failed: i suspect packed ints changes sent it over the edge).

 https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2707/
 https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2719/
 https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2723/

 All 3 cases are java 7, and all 3 cases uses -XX:+UseG1GC. (Uwe turned
 on GC randomization at lucene revolution)


 --
 lucidimagination.com

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org