Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0-ALPHA
    • Component/s: None
    • Labels:
      None

      Description

      Happened on my test machine. Is there a way to disable these tests if we cannot fix them? There are two three tests that fail most of the time and that apparently nobody knows how to fix (including me).

      There is also a typo in the error message (I'm away from home for Easter, can't do it now).

      build	06-Apr-2012 16:11:54	    [junit] Testsuite: org.apache.solr.cloud.RecoveryZkTest
      build	06-Apr-2012 16:11:54	    [junit] Testcase: testDistribSearch(org.apache.solr.cloud.RecoveryZkTest):	FAILED
      build	06-Apr-2012 16:11:54	    [junit] There are still nodes recoverying
      build	06-Apr-2012 16:11:54	    [junit] junit.framework.AssertionFailedError: There are still nodes recoverying
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.Assert.fail(Assert.java:93)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.solr.cloud.AbstractDistributedZkTestCase.waitForRecoveriesToFinish(AbstractDistributedZkTestCase.java:132)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:84)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:670)
      build	06-Apr-2012 16:11:54	    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      build	06-Apr-2012 16:11:54	    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      build	06-Apr-2012 16:11:54	    [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      build	06-Apr-2012 16:11:54	    [junit] 	at java.lang.reflect.Method.invoke(Method.java:597)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.rules.RunRules.evaluate(RunRules.java:18)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.rules.RunRules.evaluate(RunRules.java:18)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
      build	06-Apr-2012 16:11:54	    [junit] 	at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052)
      build	06-Apr-2012 16:11:54	    [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:879)
      build	06-Apr-2012 16:11:54	    [junit] 
      build	06-Apr-2012 16:11:54	    [junit] 
      build	06-Apr-2012 16:11:54	    [junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 181.377 sec
      build	06-Apr-2012 16:11:54	    [junit] 
      

        Issue Links

          Activity

          Hide
          Chris Male added a comment -

          +1 to disabling these tests. They fail often in Jenkins and locally.

          Show
          Chris Male added a comment - +1 to disabling these tests. They fail often in Jenkins and locally.
          Hide
          Dawid Weiss added a comment -

          I'll wait a few days to give people a chance to object. If I hear nothing I will successively disable those tests that fail for me often (without much feedback).

          Show
          Dawid Weiss added a comment - I'll wait a few days to give people a chance to object. If I hear nothing I will successively disable those tests that fail for me often (without much feedback).
          Hide
          Yonik Seeley added a comment -

          I looped this test (RecoveryZkTest) over night on my linux box and it didn't fail until this morning (after ~900 iterations).
          Dawid, what does your test machine look like?

          Show
          Yonik Seeley added a comment - I looped this test (RecoveryZkTest) over night on my linux box and it didn't fail until this morning (after ~900 iterations). Dawid, what does your test machine look like?
          Hide
          Dawid Weiss added a comment -

          I couldn't reproduce it either. My test machine is an ubuntu quad core (I7) and it is running full Lucene builds much like Jenkins. There are a few recurring problems that I couldn't reproduce locally no matter what. This ALSO happens on LUCENE-3808 branch which leads me to believe the problem may stem from interaction between concurrently running JVMs, not the code itself (perhaps they're modifying each other's configs, perhaps something else).

          Anything comes to your mind?

          Show
          Dawid Weiss added a comment - I couldn't reproduce it either. My test machine is an ubuntu quad core (I7) and it is running full Lucene builds much like Jenkins. There are a few recurring problems that I couldn't reproduce locally no matter what. This ALSO happens on LUCENE-3808 branch which leads me to believe the problem may stem from interaction between concurrently running JVMs, not the code itself (perhaps they're modifying each other's configs, perhaps something else). Anything comes to your mind?
          Hide
          Yonik Seeley added a comment -

          OK, I'm still on my old ubuntu quad core opteron.
          FWIW I started looping TestDistributedSearch (which has started failing consistently on jenkins) a few hours ago with tests.multiplier=3. Just 3 hours in (with each run taking ~1min) and no failures yet...

          Show
          Yonik Seeley added a comment - OK, I'm still on my old ubuntu quad core opteron. FWIW I started looping TestDistributedSearch (which has started failing consistently on jenkins) a few hours ago with tests.multiplier=3. Just 3 hours in (with each run taking ~1min) and no failures yet...
          Hide
          Dawid Weiss added a comment -

          Try looping over full ant test cycles (maybe limited to solr-core only). I did this a while back in a shell loop and redirected output to files. This brought back some failures after 30 iterations or so.

          I can also try to see if doing the above with 1 forked jvm is any different than with 3-4 forked jvms – this would make it clear if it's a concurrent tests conflict or not (and possibly provide a way to reproduce).

          Thanks for trying to clean this up – it's been bugging me for a while now.

          Show
          Dawid Weiss added a comment - Try looping over full ant test cycles (maybe limited to solr-core only). I did this a while back in a shell loop and redirected output to files. This brought back some failures after 30 iterations or so. I can also try to see if doing the above with 1 forked jvm is any different than with 3-4 forked jvms – this would make it clear if it's a concurrent tests conflict or not (and possibly provide a way to reproduce). Thanks for trying to clean this up – it's been bugging me for a while now.
          Hide
          Yonik Seeley added a comment - - edited

          FWIW I started looping TestDistributedSearch (which has started failing consistently on jenkins) a few hours ago with tests.multiplier=3. Just 3 hours in (with each run taking ~1min) and no failures yet...

          Update: I just got a failure after 642 runs. A response mismatch here:

              // random value sort
              for (String f : fieldNames) {
                query("q","*:*", "sort",f+" desc");
          

          The actual number of documents failed to match... and no other exceptions in the test, so I'm not sure how that can happen. Anyway, it doesn't appear to be related to the super high failure rate on our freebsd-jenkins, which I am unable to reproduce so far.

          edit: I've started looping the full "ant test" to see how often it fails on my system.

          Show
          Yonik Seeley added a comment - - edited FWIW I started looping TestDistributedSearch (which has started failing consistently on jenkins) a few hours ago with tests.multiplier=3. Just 3 hours in (with each run taking ~1min) and no failures yet... Update: I just got a failure after 642 runs. A response mismatch here: // random value sort for ( String f : fieldNames) { query( "q" , "*:*" , "sort" ,f+ " desc" ); The actual number of documents failed to match... and no other exceptions in the test, so I'm not sure how that can happen. Anyway, it doesn't appear to be related to the super high failure rate on our freebsd-jenkins, which I am unable to reproduce so far. edit: I've started looping the full "ant test" to see how often it fails on my system.
          Hide
          Dawid Weiss added a comment -

          This is weird. I've had something like this before on the branch – see SOLR-3233. If you go back to that particular revision it was reproducible (but no longer is with that seed). I didn't investigate further.

          Show
          Dawid Weiss added a comment - This is weird. I've had something like this before on the branch – see SOLR-3233 . If you go back to that particular revision it was reproducible (but no longer is with that seed). I didn't investigate further.
          Hide
          Yonik Seeley added a comment -

          I've been looping the full "ant test" for a while... it failed after about 4 hours (30 runs) the first time and the second time hasn't failed yet (over 8 hours).

          Show
          Yonik Seeley added a comment - I've been looping the full "ant test" for a while... it failed after about 4 hours (30 runs) the first time and the second time hasn't failed yet (over 8 hours).
          Hide
          Yonik Seeley added a comment -

          Something weird is going on with the nightly builds (which mostly fail) vs the normal tests (which mostly pass) on jenkins.

          Anyway, it seems like we should keep these tests enabled since they do mostly pass with the normal tests and provide critical coverage.

          Show
          Yonik Seeley added a comment - Something weird is going on with the nightly builds (which mostly fail) vs the normal tests (which mostly pass) on jenkins. Anyway, it seems like we should keep these tests enabled since they do mostly pass with the normal tests and provide critical coverage.
          Hide
          Hoss Man added a comment -
          • nightly builds seem to fail almost every time
          • test only builds seem to pass almost every time

          ...are folks remembering to use "-Dtests.nightly=true" when trying to reproduce this?

          I tried the reproduce line from nightly build #1819 and got the same ConnectException as jenkins three times in a row...

          hossman@bester:~/lucene/dev/solr$ ant test -Dtestcase=TestDistributedSearch -Dtestmethod=testDistribSearch -Dtests.seed=-64cffe89df6d3a71:-2543436b41d480f3:21aa64ce023d4a8a -Dtests.nightly=true -Dargs="-Dfile.encoding=ISO8859-1"
          
          Show
          Hoss Man added a comment - nightly builds seem to fail almost every time test only builds seem to pass almost every time ...are folks remembering to use "-Dtests.nightly=true" when trying to reproduce this? I tried the reproduce line from nightly build #1819 and got the same ConnectException as jenkins three times in a row... hossman@bester:~/lucene/dev/solr$ ant test -Dtestcase=TestDistributedSearch -Dtestmethod=testDistribSearch -Dtests.seed=-64cffe89df6d3a71:-2543436b41d480f3:21aa64ce023d4a8a -Dtests.nightly=true -Dargs="-Dfile.encoding=ISO8859-1"
          Hide
          Hoss Man added a comment -

          ignoring the seed, and just trying the test with "-Dtests.nightly=true" i've only seen this test pass once (and i might have had a typo in that nightly param – it was the first time i tried it and i didn't have a shell log).

          Unless i'm missing something...

          • BaseDistributedSearchTestCase.createServers initializes the following pairwise...
            • protected List<JettySolrRunner> jettys
            • protected List<SolrServer> clients
          • TestDistributedSearch.doTest then...
            • copies those lists into local upJettys and upClients instances and maintains a list of "upShards"
            • iteratively shutsdown some number of jetty instances, removing from upJettys, upShards, and upClients
            • passes upShards and upClients to queryPartialResults
          • TestDistributedSearch.queryPartialResults ...
            • does some random quering of upShards and upClients
            • if stress is non-zero (which it is if it's nightly) then it also spins up a bunch of threads using a client from the original "clients" list

          ...which seems fundamentally flawed to me ... because each "client" knows about a specific jetty instance, and the test has explicitly shut down some jetty instances.

          Is this just a typo? are the refs to "clients" in queryPartialResults all just suppose to be "upClients" ?

          Show
          Hoss Man added a comment - ignoring the seed, and just trying the test with "-Dtests.nightly=true" i've only seen this test pass once (and i might have had a typo in that nightly param – it was the first time i tried it and i didn't have a shell log). Unless i'm missing something... BaseDistributedSearchTestCase.createServers initializes the following pairwise... protected List<JettySolrRunner> jettys protected List<SolrServer> clients TestDistributedSearch.doTest then... copies those lists into local upJettys and upClients instances and maintains a list of "upShards" iteratively shutsdown some number of jetty instances, removing from upJettys, upShards, and upClients passes upShards and upClients to queryPartialResults TestDistributedSearch.queryPartialResults ... does some random quering of upShards and upClients if stress is non-zero (which it is if it's nightly) then it also spins up a bunch of threads using a client from the original "clients" list ...which seems fundamentally flawed to me ... because each "client" knows about a specific jetty instance, and the test has explicitly shut down some jetty instances. Is this just a typo? are the refs to "clients" in queryPartialResults all just suppose to be "upClients" ?
          Hide
          Yonik Seeley added a comment -

          if stress is non-zero (which it is if it's nightly)

          Gack - I don't know when that happened... seems like we should have some degree of "stress" (i.e. query from multiple threads) in the tests that run after any changes!

          Is this just a typo? are the refs to "clients" in queryPartialResults all just suppose to be "upClients" ?

          shrug... I never reviewed the partial results stuff, but I guess the changes to this test are from this commit?

          r1294995 | ryan | 2012-02-29 02:32:02 -0500 (Wed, 29 Feb 2012) | 1 line
          SOLR-3134:  Adding test and fix from Russell Black
          

          Thanks for looking into that Hoss!

          Show
          Yonik Seeley added a comment - if stress is non-zero (which it is if it's nightly) Gack - I don't know when that happened... seems like we should have some degree of "stress" (i.e. query from multiple threads) in the tests that run after any changes! Is this just a typo? are the refs to "clients" in queryPartialResults all just suppose to be "upClients" ? shrug ... I never reviewed the partial results stuff, but I guess the changes to this test are from this commit? r1294995 | ryan | 2012-02-29 02:32:02 -0500 (Wed, 29 Feb 2012) | 1 line SOLR-3134: Adding test and fix from Russell Black Thanks for looking into that Hoss!
          Hide
          Hoss Man added a comment -

          looking at the province of the test method, it comes from SOLR-3134 and seems to be a cut/paste clone/refactoring of the "query" method from the base class with the clients/jetties replaced by upclients and upjetties – but this part was clearly missed.

          Committed revision 1311477.

          Show
          Hoss Man added a comment - looking at the province of the test method, it comes from SOLR-3134 and seems to be a cut/paste clone/refactoring of the "query" method from the base class with the clients/jetties replaced by upclients and upjetties – but this part was clearly missed. Committed revision 1311477.
          Hide
          Hoss Man added a comment -

          for got to mention: that commit causes hte test to pass reliably for me ~20 times, including all of the reproduce lines from the last 5 failed nightly builds

          Show
          Hoss Man added a comment - for got to mention: that commit causes hte test to pass reliably for me ~20 times, including all of the reproduce lines from the last 5 failed nightly builds
          Hide
          Mark Miller added a comment -

          seems like we should have some degree of "stress"

          Because I was not worried about more query side testing, for simplicity, all of those solrcloud tests don't use the stress mode. Those tests are all focused on indexing and then querying simply for correctness - we have solrcloud stress querying in previous tests that where done. When developing the indexing side, it wasn't worth the refactoring to me. Looks like you have done some of needed refactoring later given the refs to upCliens and downClients.

          Show
          Mark Miller added a comment - seems like we should have some degree of "stress" Because I was not worried about more query side testing, for simplicity, all of those solrcloud tests don't use the stress mode. Those tests are all focused on indexing and then querying simply for correctness - we have solrcloud stress querying in previous tests that where done. When developing the indexing side, it wasn't worth the refactoring to me. Looks like you have done some of needed refactoring later given the refs to upCliens and downClients.
          Hide
          Dawid Weiss added a comment -

          @Yonik: I run trunk tests in non-nightly mode and I see at least 1-2 failures a day (runs every two hours). This does change over time though as i merge with new commits. Some tests are frequent offenders though, like the latest one –

          build	10-Apr-2012 00:25:25	    [junit] Testsuite: org.apache.solr.cloud.OverseerTest
          build	10-Apr-2012 00:25:25	    [junit] Testcase: testShardLeaderChange(org.apache.solr.cloud.OverseerTest):	FAILED
          build	10-Apr-2012 00:25:25	    [junit] Unexpected shard leader coll:collection1 shard:shard1 expected:<core4> but was:<null>
          build	10-Apr-2012 00:25:25	    [junit] junit.framework.AssertionFailedError: Unexpected shard leader coll:collection1 shard:shard1 expected:<core4> but was:<null>
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.Assert.fail(Assert.java:93)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.Assert.failNotEquals(Assert.java:647)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.Assert.assertEquals(Assert.java:128)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:549)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:711)
          build	10-Apr-2012 00:25:25	    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          build	10-Apr-2012 00:25:25	    [junit] 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          build	10-Apr-2012 00:25:25	    [junit] 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          build	10-Apr-2012 00:25:25	    [junit] 	at java.lang.reflect.Method.invoke(Method.java:597)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.rules.RunRules.evaluate(RunRules.java:18)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.rules.RunRules.evaluate(RunRules.java:18)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
          build	10-Apr-2012 00:25:25	    [junit] 	at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052)
          build	10-Apr-2012 00:25:25	    [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:879)
          build	10-Apr-2012 00:25:25	    [junit] 
          build	10-Apr-2012 00:25:25	    [junit] 
          build	10-Apr-2012 00:25:25	    [junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 92.518 sec
          
          Show
          Dawid Weiss added a comment - @Yonik: I run trunk tests in non-nightly mode and I see at least 1-2 failures a day (runs every two hours). This does change over time though as i merge with new commits. Some tests are frequent offenders though, like the latest one – build 10-Apr-2012 00:25:25 [junit] Testsuite: org.apache.solr.cloud.OverseerTest build 10-Apr-2012 00:25:25 [junit] Testcase: testShardLeaderChange(org.apache.solr.cloud.OverseerTest): FAILED build 10-Apr-2012 00:25:25 [junit] Unexpected shard leader coll:collection1 shard:shard1 expected:<core4> but was:<null> build 10-Apr-2012 00:25:25 [junit] junit.framework.AssertionFailedError: Unexpected shard leader coll:collection1 shard:shard1 expected:<core4> but was:<null> build 10-Apr-2012 00:25:25 [junit] at org.junit.Assert.fail(Assert.java:93) build 10-Apr-2012 00:25:25 [junit] at org.junit.Assert.failNotEquals(Assert.java:647) build 10-Apr-2012 00:25:25 [junit] at org.junit.Assert.assertEquals(Assert.java:128) build 10-Apr-2012 00:25:25 [junit] at org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:549) build 10-Apr-2012 00:25:25 [junit] at org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:711) build 10-Apr-2012 00:25:25 [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) build 10-Apr-2012 00:25:25 [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) build 10-Apr-2012 00:25:25 [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) build 10-Apr-2012 00:25:25 [junit] at java.lang.reflect.Method.invoke(Method.java:597) build 10-Apr-2012 00:25:25 [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) build 10-Apr-2012 00:25:25 [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) build 10-Apr-2012 00:25:25 [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) build 10-Apr-2012 00:25:25 [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) build 10-Apr-2012 00:25:25 [junit] at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) build 10-Apr-2012 00:25:25 [junit] at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642) build 10-Apr-2012 00:25:25 [junit] at org.junit.rules.RunRules.evaluate(RunRules.java:18) build 10-Apr-2012 00:25:25 [junit] at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) build 10-Apr-2012 00:25:25 [junit] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) build 10-Apr-2012 00:25:25 [junit] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) build 10-Apr-2012 00:25:25 [junit] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) build 10-Apr-2012 00:25:25 [junit] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) build 10-Apr-2012 00:25:25 [junit] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) build 10-Apr-2012 00:25:25 [junit] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) build 10-Apr-2012 00:25:25 [junit] at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) build 10-Apr-2012 00:25:25 [junit] at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) build 10-Apr-2012 00:25:25 [junit] at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) build 10-Apr-2012 00:25:25 [junit] at org.junit.rules.RunRules.evaluate(RunRules.java:18) build 10-Apr-2012 00:25:25 [junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:300) build 10-Apr-2012 00:25:25 [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) build 10-Apr-2012 00:25:25 [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518) build 10-Apr-2012 00:25:25 [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052) build 10-Apr-2012 00:25:25 [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:879) build 10-Apr-2012 00:25:25 [junit] build 10-Apr-2012 00:25:25 [junit] build 10-Apr-2012 00:25:25 [junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 92.518 sec

            People

            • Assignee:
              Hoss Man
              Reporter:
              Dawid Weiss
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development