Great, thanks Kaare! Dawid
P.S. Indeed, running tests as root is not a good idea... :D On Tue, May 5, 2015 at 1:42 PM, Kåre Brandborg <[email protected]> wrote: > After further debugging into this failing test and issue we discovered that > the reason why this tests failed in our build environment was due to our > build runner running with elevated privileges (as root). > > The test assert that a folder is not available and it does that by changing > the permissions of the folder to write/execute only for a regular user/group > (removing the read flag). > > The root user was still able to access the folder and that’s why the test > failed. > > We have updated our build runner to run as a regular user now - and the tests > seem to progress without any errors so far. > > (Since this is opensource I guess other people could use our findings). > > Thanks > > Kaare Brandborg > > >> On 05 May 2015, at 12:11, Dawid Weiss <[email protected]> wrote: >> >> The assertion alone isn't helpful. Solr tests dump tons of logs along >> the way, if you can copy these to a text file and then create a jira >> issue (reference it here) then perhaps somebody can look into the >> cause of the problem (or you can do it -- it's open source after all >> :). >> >> https://issues.apache.org/jira/secure/Dashboard.jspa >> >> Dawid >> >> On Tue, May 5, 2015 at 11:29 AM, Kåre Brandborg <[email protected]> wrote: >>> I’m a colleague of Per from who I’ve taken over the task to try to get our >>> test environment to build Solr 5.1 and compile and run a test suite with >>> green lights. >>> >>> I’ll try to elaborate a little more about our progress. >>> >>> We are currently using Teamcity CI and we are running our tests on an >>> Ubuntu 12.04 x64 with jdk7u76 (x64) and ant 1.9.4. >>> >>> We have made a single change to the: ./lucene/ivy-settings.xml file (to >>> point it to use our internal repository to resolve artifacts. >>> >>> I’ve observed that the following test is failing for us on every run (Have >>> made 5 runs so far on the configuration above): >>> >>> 2> 1490839 T6144 oasc.CachingDirectoryFactory.close Closing directory: >>> /opt/buildagent/work/6906da56abce9b00/solr/build/solr-core/test/J1/temp/solr.core.TestCoreDiscovery >>> 93911594584047D7-001/tempDir-001/core2/core2/index >>> 2> 1490840 T6144 oas.SolrTestCaseJ4.tearDown ###Ending testCoreDirCantRead >>> 2> NOTE: reproduce with: ant test -Dtestcase=TestCoreDiscovery >>> -Dtests.method=testCoreDirCantRead -Dtests.seed=93911594584047D7 >>> -Dtests.slow=true -Dtests.locale=ar_KW -Dtests.timezone=Australia/West >>> -Dtests.asserts=true -Dtests.file.encoding=US-ASCII >>> FAILURE 0.72s J1 | TestCoreDiscovery.testCoreDirCantRead <<< >>>> Throwable #1: java.lang.AssertionError >>>> at >>>> __randomizedtesting.SeedInfo.seed([93911594584047D7:EED5C1C227C789A5]:0) >>>> at >>>> org.apache.solr.core.TestCoreDiscovery.testCoreDirCantRead(TestCoreDiscovery.java:286) >>>> at java.lang.Thread.run(Thread.java:745) >>> 2> 1490889 T6144 oas.SolrTestCaseJ4.setUp ###Starting testAlternateCoreDir >>> >>> And we are running ant with the following parameter: >>> >>> ant -f build.xml -Dtests.haltonfailure=false test >>> >>> Looking for any help on what can be causing these tests to fail. We suspect >>> a misconfiguration in our environment but are unsure where to look. >>> >>> Thanks >>> >>> Kaare Brandborg >>> >>> >>>> On 04 May 2015, at 14:30, Dawid Weiss <[email protected]> wrote: >>>> >>>>> [junit4] ERROR 3.81s J2 | TestDirectoryTaxonomyWriter.testConcurrency >>>>> <<< >>>>> [junit4] > Throwable #1: java.lang.NoSuchMethodError: >>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>> >>>> Sorry about the delay. This indicates your code was compiled with >>>> JDK1.8 but is executed with Java < 1.8. This method's signature used >>>> to be an interface, but is a covariant pointing at a specialized >>>> subclass in 1.8. >>>> >>>> You need to compile the code with the version of Java you intend to >>>> run with. Things will in general work if you compile with an older >>>> version and try to run with a newer version but not the other way >>>> around. >>>> >>>> You can cross-compile with javac from a newer version of the JDK to an >>>> older version but you'd have to specify bootclasspath to the older >>>> version anyway (bytecode/source flag in javac is not enough) so >>>> there's really no sensible reason to do it in the first place. >>>> >>>> Dawid >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
