Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2723 - Failure
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
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
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
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
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
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
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
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