You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Per Steffensen <st...@designware.dk> on 2015/04/24 10:24:35 UTC
Running 5.1.0 test-suite via maven
I have checked out tag lucene_solr_5_1_0 and try to run the test-suite
using maven
ant get-maven-poms
cd maven-build/
mvn -N -Pbootstrap -DskipTests install
mvn -Dmaven.test.failure.ignore=true test
The following tests fail running the test-suite this way using maven
* SuggestFieldTest - all test methods fail
* hadoop.MorphlineBasicMiniMRTest and hadoop.MorphlineGoLiveMiniMRTest
- setupClass fails
* TestCoreDiscovery.testCoreDirCantRead - test fails
Now trying to run in Eclipse
ant eclipse
Open Eclipse and import project
Running the failing tests
* SuggestFieldTest - test passes
* hadoop.MorphlineBasicMiniMRTest and hadoop.MorphlineGoLiveMiniMRTest -
setupClass fails
* TestCoreDiscovery.testCoreDirCantRead - test passes
Can anyone explain this? Would expect a green test-suite for a released
solr/lucene.
What might be wrong with SuggestFieldTest and TestCoreDiscovery tests
run through maven (fail), compared to run through Eclipse (pass)?
Why does the Morphline tests fail (both maven and Eclipse)?
It is the correct way to run tests using maven? It there another way the
test-suite is usually run (e.g. using ant)?
Thanks in advance.
Regards, Per Steffensen
------------------------------------- fail stacktraces
-----------------------------------
* SuggestFieldTest fails using maven (not Eclipse) like this:
java.lang.IllegalArgumentException: An SPI class of type
org.apache.lucene.codecs.PostingsFormat with name 'completion' does not
exist. You need to add the corresponding JAR file supporting this SPI
to your classpath. The current classpath supports the following names:
[MockRandom, RAMOnly, LuceneFixedGap, LuceneVarGapFixedInterval,
LuceneVarGapDocFreqInterval, TestBloomFilteredLucenePostings, Asserting,
Lucene50, BlockTreeOrds, BloomFilter, Direct, FSTOrd50, FST50, Memory,
SimpleText]
at
org.apache.lucene.util.NamedSPILoader.lookup(NamedSPILoader.java:111)
at
org.apache.lucene.codecs.PostingsFormat.forName(PostingsFormat.java:100)
at
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.<init>(PerFieldPostingsFormat.java:255)
at
org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:336)
at
org.apache.lucene.index.SegmentCoreReaders.<init>(SegmentCoreReaders.java:104)
at org.apache.lucene.index.SegmentReader.<init>(SegmentReader.java:65)
at
org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:132)
at
org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:184)
at
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:99)
at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:429)
at
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:343)
at
org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:280)
at
org.apache.lucene.search.suggest.document.SuggestFieldTest.testReturnedDocID(SuggestFieldTest.java:459)
* The Morphline tests fail (both maven and Eclipse) like this:
org.apache.hadoop.yarn.exceptions.YarnRuntimeException: java.lang.NoClassDefFoundError: org/apache/hadoop/yarn/server/applicationhistoryservice/ApplicationHistoryWriter
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at org.apache.hadoop.yarn.server.resourcemanager.ResourceManager.createRMApplicationHistoryWriter(ResourceManager.java:357)
at org.apache.hadoop.yarn.server.resourcemanager.ResourceManager$RMActiveServices.serviceInit(ResourceManager.java:468)
at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
at org.apache.hadoop.yarn.server.resourcemanager.ResourceManager.createAndInitActiveServices(ResourceManager.java:989)
at org.apache.hadoop.yarn.server.resourcemanager.ResourceManager.serviceInit(ResourceManager.java:255)
at org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
at org.apache.solr.hadoop.hack.MiniYARNCluster$ResourceManagerWrapper.serviceStart(MiniYARNCluster.java:200)
at org.apache.hadoop.service.AbstractService.start(AbstractService.java:193)
at org.apache.hadoop.service.CompositeService.serviceStart(CompositeService.java:120)
at org.apache.hadoop.service.AbstractService.start(AbstractService.java:193)
at org.apache.solr.hadoop.hack.MiniMRClientClusterFactory.create(MiniMRClientClusterFactory.java:83)
at org.apache.solr.hadoop.hack.MiniMRCluster.<init>(MiniMRCluster.java:191)
at org.apache.solr.hadoop.hack.MiniMRCluster.<init>(MiniMRCluster.java:179)
at org.apache.solr.hadoop.hack.MiniMRCluster.<init>(MiniMRCluster.java:171)
at org.apache.solr.hadoop.MorphlineBasicMiniMRTest.setupClass(MorphlineBasicMiniMRTest.java:174)
* TestCoreDiscovery.testCoreDirCantRead fails using maven (not Eclipse)
like this:
java.lang.AssertionError: null
at __randomizedtesting.SeedInfo.seed([C815A145972F10FC:B5517513E8A8DE8E]:0)
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNull(Assert.java:551)
at org.junit.Assert.assertNull(Assert.java:562)
at org.apache.solr.core.TestCoreDiscovery.testCoreDirCantRead(TestCoreDiscovery.java:286)
Re: Running 5.1.0 test-suite via maven
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
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 <ka...@liace.dk> 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 <da...@cs.put.poznan.pl> 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 <ka...@liace.dk> 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 <da...@cs.put.poznan.pl> 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: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Running 5.1.0 test-suite via maven
Posted by Kåre Brandborg <ka...@liace.dk>.
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 <da...@cs.put.poznan.pl> 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 <ka...@liace.dk> 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 <da...@cs.put.poznan.pl> 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: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Running 5.1.0 test-suite via maven
Posted by Per Steffensen <pe...@gmail.com>.
On 05/05/15 15:05, Dawid Weiss wrote:
> I'm part of Apache Lucene and I try to make every release meet quality
> standards, but Solr tests are quite complex and have had a long
> history of being very difficult to fix. If you search mailing list
> archives you'll see at least a few attempts and continuous efforts
> from various people aiming at stabilizing these test.
Yes, I know too well
>
> This said, if you're asking whether there was a "green" light before the release
> then yes
Yes, that was what would expect, and therefor kept thinking that it must
be something with out build-environment. And therefore likely no need
for a JIRA
> -- anybody who votes for the release to proceed ran the
> smoketester and this in turn runs all the tests. But machines and
> environments vary. I don't know anybody who'd run development runs as
> root, for example (which you apparently did).
Yes, that is clearly a mistake
>
> The problems you initially experienced were your environment setup
> problems (different compile JDK compared to runtime JDK), they don't
> have much to do with Solr tests too.
Exactly
>
> Dawid
Regards, Per Steffensen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Running 5.1.0 test-suite via maven
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
I'm part of Apache Lucene and I try to make every release meet quality
standards, but Solr tests are quite complex and have had a long
history of being very difficult to fix. If you search mailing list
archives you'll see at least a few attempts and continuous efforts
from various people aiming at stabilizing these test.
This said, if you're asking whether there was a "green" light before the release
then yes -- anybody who votes for the release to proceed ran the
smoketester and this in turn runs all the tests. But machines and
environments vary. I don't know anybody who'd run development runs as
root, for example (which you apparently did).
The problems you initially experienced were your environment setup
problems (different compile JDK compared to runtime JDK), they don't
have much to do with Solr tests too.
Dawid
On Tue, May 5, 2015 at 2:48 PM, Per Steffensen <pe...@gmail.com> wrote:
> I believe a JIRA will be about fixing a problem. But right now it is not so
> much about fixing a problem, it is about telling if there is a problem in
> the code to fix, or if it is just us doing something wrong. We want to be
> able to run the test-suite with the same test-results as you get at Apache
> CI. So if this particular test also fail at Apache CI for version 5.1.0 we
> have no problem. It is just that I would expect you to have seen a green
> test-suite in Apache CI on 5.1.0 code before releasing it. The fact that we
> do not see a green test-suite on 5.1.0 make us wonder why - do we run the
> test-suite correctly, or ... ?
>
> Can you confirm that you have seen a green test-suite at Apache CI on 5.1.0
> code? Because then we have a problem in my organization, and there is
> nothing to fix on Apache side, and therefore no JIRA to open.
>
> If the test is red also on you side, and it is not because we run the
> test-suite in a wrong way, of course it should be corrected, and that would
> call for a JIRA. But right now we are not sure.
>
> Regards, Per Steffensen
>
>
> On 05/05/15 14:08, Mark Miller wrote:
>
> +1 - I'd file JIRAs.
>
> - Mark
>
> On Tue, May 5, 2015 at 6:13 AM Dawid Weiss <da...@cs.put.poznan.pl>
> 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 <ka...@liace.dk> 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 <da...@cs.put.poznan.pl>
>> >> 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: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Running 5.1.0 test-suite via maven
Posted by Per Steffensen <pe...@gmail.com>.
I believe a JIRA will be about fixing a problem. But right now it is not
so much about fixing a problem, it is about telling if there is a
problem in the code to fix, or if it is just us doing something wrong.
We want to be able to run the test-suite with the same test-results as
you get at Apache CI. So if this particular test also fail at Apache CI
for version 5.1.0 we have no problem. It is just that I would expect you
to have seen a green test-suite in Apache CI on 5.1.0 code before
releasing it. The fact that we do not see a green test-suite on 5.1.0
make us wonder why - do we run the test-suite correctly, or ... ?
Can you confirm that you have seen a green test-suite at Apache CI on
5.1.0 code? Because then we have a problem in my organization, and there
is nothing to fix on Apache side, and therefore no JIRA to open.
If the test is red also on you side, and it is not because we run the
test-suite in a wrong way, of course it should be corrected, and that
would call for a JIRA. But right now we are not sure.
Regards, Per Steffensen
On 05/05/15 14:08, Mark Miller wrote:
> +1 - I'd file JIRAs.
>
> - Mark
>
> On Tue, May 5, 2015 at 6:13 AM Dawid Weiss
> <dawid.weiss@cs.put.poznan.pl <ma...@cs.put.poznan.pl>>
> 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 <kaare@liace.dk
> <ma...@liace.dk>> 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
> <dawid.weiss@cs.put.poznan.pl
> <ma...@cs.put.poznan.pl>> 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: dev-unsubscribe@lucene.apache.org
> <ma...@lucene.apache.org>
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> <ma...@lucene.apache.org>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> <ma...@lucene.apache.org>
> > For additional commands, e-mail: dev-help@lucene.apache.org
> <ma...@lucene.apache.org>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> <ma...@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org
> <ma...@lucene.apache.org>
>
Re: Running 5.1.0 test-suite via maven
Posted by Mark Miller <ma...@gmail.com>.
+1 - I'd file JIRAs.
- Mark
On Tue, May 5, 2015 at 6:13 AM Dawid Weiss <da...@cs.put.poznan.pl>
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 <ka...@liace.dk> 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 <da...@cs.put.poznan.pl>
> 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: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Running 5.1.0 test-suite via maven
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
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 <ka...@liace.dk> 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 <da...@cs.put.poznan.pl> 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: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Running 5.1.0 test-suite via maven
Posted by Kåre Brandborg <ka...@liace.dk>.
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 <da...@cs.put.poznan.pl> 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Running 5.1.0 test-suite via maven
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
> [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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Running 5.1.0 test-suite via maven
Posted by Per Steffensen <st...@designware.dk>.
Now trying to run ant test with java7. I get the follow failing tests. Hmmm
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyWriter
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestDirectoryTaxonomyWriter -Dtests.method=testConcurrency
-Dtests.seed=6A95BF7E6A49187D -Dtests.slow=true -Dtests.locale=en_ZA
-Dtests.timezone=America/St_Vincent -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] ERROR 3.81s J2 |
TestDirectoryTaxonomyWriter.testConcurrency <<<
[junit4] > Throwable #1: java.lang.NoSuchMethodError:
java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
[junit4] > at
__randomizedtesting.SeedInfo.seed([6A95BF7E6A49187D:CC657DE30B1AF8B4]:0)
[junit4] > at
org.apache.lucene.facet.taxonomy.directory.TestDirectoryTaxonomyWriter.testConcurrency(TestDirectoryTaxonomyWriter.java:309)
[junit4] > at java.lang.Thread.run(Thread.java:744)
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene50):
{$full_path$=PostingsFormat(name=LuceneVarGapDocFreqInterval),
$payloads$=PostingsFormat(name=LuceneVarGapDocFreqInterval),
$facets=PostingsFormat(name=LuceneVarGapFixedInterval)},
docValues:{$facets=DocValuesFormat(name=Lucene50)},
sim=DefaultSimilarity, locale=en_ZA, timezone=America/St_Vincent
[junit4] 2> NOTE: Mac OS X 10.10.2 x86_64/Oracle Corporation
1.7.0_51 (64-bit)/cpus=8,threads=1,free=193456536,total=236453888
[junit4] 2> NOTE: All tests run in this JVM:
[TestTaxonomyCombined, TestDirectoryTaxonomyWriter]
[junit4] Completed on J2 in 6.67s, 15 tests, 1 error <<< FAILURES!
[junit4]
[junit4] Suite: org.apache.lucene.facet.TestMultipleIndexFields
[junit4] Completed on J2 in 1.43s, 5 tests
[junit4]
[junit4] Suite:
org.apache.lucene.facet.taxonomy.TestTaxonomyFacetSumValueSource
[junit4] Completed on J2 in 2.62s, 9 tests
[junit4]
[junit4] Suite: org.apache.lucene.facet.TestDrillSideways
[junit4] Completed on J3 in 10.73s, 6 tests
[junit4]
[junit4] Suite:
org.apache.lucene.facet.taxonomy.directory.TestConcurrentFacetedIndexing
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=TestConcurrentFacetedIndexing -Dtests.method=testConcurrency
-Dtests.seed=6A95BF7E6A49187D -Dtests.slow=true -Dtests.locale=de_DE
-Dtests.timezone=SST -Dtests.asserts=true -Dtests.file.encoding=UTF-8
[junit4] ERROR 1.54s J2 |
TestConcurrentFacetedIndexing.testConcurrency <<<
[junit4] > Throwable #1: java.lang.NoSuchMethodError:
java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView;
[junit4] > at
__randomizedtesting.SeedInfo.seed([6A95BF7E6A49187D:CC657DE30B1AF8B4]:0)
[junit4] > at
org.apache.lucene.facet.taxonomy.directory.TestConcurrentFacetedIndexing.testConcurrency(TestConcurrentFacetedIndexing.java:142)
[junit4] > at java.lang.Thread.run(Thread.java:744)
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene50):
{$full_path$=PostingsFormat(name=Direct),
$payloads$=PostingsFormat(name=Direct)}, docValues:{},
sim=RandomSimilarityProvider(queryNorm=true,coord=no): {}, locale=de_DE,
timezone=SST
[junit4] 2> NOTE: Mac OS X 10.10.2 x86_64/Oracle Corporation
1.7.0_51 (64-bit)/cpus=8,threads=1,free=168753144,total=240648192
[junit4] 2> NOTE: All tests run in this JVM:
[TestTaxonomyCombined, TestDirectoryTaxonomyWriter,
TestMultipleIndexFields, TestTaxonomyFacetSumValueSource,
TestConcurrentFacetedIndexing]
[junit4] Completed on J2 in 1.61s, 1 test, 1 error <<< FAILURES!
On 24/04/15 22:11, Dawid Weiss wrote:
> 1. does it fail when you run it via ant (ant build)?
> 2. the problem is very likely in dependencies declared in Maven (as
> compared to what the ivy dependencies are).
>
> Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Running 5.1.0 test-suite via maven
Posted by Per Steffensen <st...@designware.dk>.
I tried running "ant test". I get the test-errors shown below
* "java.lang.NoClassDefFoundError: Could not initialize class
java.lang.UNIXProcess" might be because I am running it on java 8 (I
thought source/target set to 1.7 would be good enough)
* Do not understand why I get "java.lang.NoClassDefFoundError: Could not
initialize class org.apache.hadoop.util.StringUtils".
org.apache.hadoop/hadoop-common/2.6.0 is in ~/.ivy2 (and ~/.m2 for that
matter)
Any help appreciated!
Regards, Per Steffensen
-----
[junit4] Suite: org.apache.solr.cloud.hdfs.StressHdfsTest
[junit4] 2> Creating dataDir:
/Users/steff/LiaceDisk/lucene_solr_5_1_0/solr/build/solr-core/test/J1/temp/solr.cloud.hdfs.StressHdfsTest
9A1D1C06EE13AC04-001/init-core-data-001
[junit4] 2> 1527744 T5936
oas.BaseDistributedSearchTestCase.initHostContext Setting hostContext
system property: /
[junit4] 2> 1529116 T5936 oas.SolrTestCaseJ4.deleteCore ###deleteCore
[junit4] 2> NOTE: test params are: codec=Asserting(Lucene50),
sim=RandomSimilarityProvider(queryNorm=true,coord=no): {}, locale=hu_HU,
timezone=Pacific/Truk
[junit4] 2> NOTE: Mac OS X 10.10.2 x86_64/Oracle Corporation
1.8.0_25 (64-bit)/cpus=8,threads=1,free=285813160,total=440401920
[junit4] 2> NOTE: All tests run in this JVM: [HighlighterTest,
CoreMergeIndexesAdminHandlerTest, OpenCloseCoreStressTest,
FileUtilsTest, HdfsBasicDistributedZk2Test, TestExactSharedStatsCache,
DistributedQueryComponentCustomSortTest, TestCloudInspectUtil,
TestQuerySenderNoQuery, SimplePostToolTest, TestSchemaNameResource,
TestFieldCollectionResource, BasicFunctionalityTest,
TermVectorComponentDistributedTest, IndexBasedSpellCheckerTest,
LeaderElectionTest, TestRandomDVFaceting, ShowFileRequestHandlerTest,
TestReplicationHandler, InfoHandlerTest, DistributedQueueTest,
TestStressReorder, CursorPagingTest, ScriptEngineTest,
XmlUpdateRequestHandlerTest, ShardRoutingCustomTest,
ClusterStateUpdateTest, TestJsonRequest, TestBM25SimilarityFactory,
MigrateRouteKeyTest, RollingRestartTest, DocValuesTest, PolyFieldTest,
TestSimpleQParserPlugin, TimeZoneUtilsTest, ReplicationFactorTest,
TestJettySolrRunner, DistributedSuggestComponentTest, TestRTGBase,
TestBlobHandler, TestMaxScoreQueryParser, TestHashQParserPlugin,
CSVRequestHandlerTest, TestDocumentBuilder, SolrPluginUtilsTest,
DistributedFacetPivotSmallTest, TestManagedSchema, RecoveryZkTest,
HdfsBasicDistributedZkTest, SimpleCollectionCreateDeleteTest,
TestFastWriter, TestRequestStatusCollectionAPI, DistanceUnitsTest,
TestConfigSets, TestManagedResourceStorage, BadCopyFieldTest,
TestPartialUpdateDeduplication, TestCryptoKeys, MinimalSchemaTest,
SolrInfoMBeanTest, TestCursorMarkWithoutUniqueKey,
TestDistributedGrouping, TestGroupingSearch, TestHighlightDedupGrouping,
TestJoin, TestTolerantSearch, TestTrie,
PathHierarchyTokenizerFactoryTest, TestReversedWildcardFilterFactory,
ActionThrottleTest, AliasIntegrationTest, AssignTest,
BasicDistributedZk2Test, FullSolrCloudDistribCmdsTest,
LeaderInitiatedRecoveryOnCommitTest, OverseerTest,
SharedFSAutoReplicaFailoverUtilsTest, SliceStateTest, SyncSliceTest,
ZkNodePropsTest, HdfsChaosMonkeySafeLeaderTest,
HdfsCollectionsAPIDistributedZkTest, HdfsWriteToMultipleCollectionsTest,
StressHdfsTest]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=StressHdfsTest -Dtests.seed=9A1D1C06EE13AC04
-Dtests.slow=true -Dtests.locale=hu_HU -Dtests.timezone=Pacific/Truk
-Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.00s J1 | StressHdfsTest (suite) <<<
[junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could
not initialize class java.lang.UNIXProcess
[junit4] > at
__randomizedtesting.SeedInfo.seed([9A1D1C06EE13AC04]:0)
[junit4] > at java.lang.ProcessImpl.start(ProcessImpl.java:130)
[junit4] > at
java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
[junit4] > at
org.apache.hadoop.util.Shell.runCommand(Shell.java:485)
[junit4] > at org.apache.hadoop.util.Shell.run(Shell.java:455)
[junit4] > at
org.apache.hadoop.util.Shell$ShellCommandExecutor.execute(Shell.java:715)
[junit4] > at
org.apache.hadoop.util.Shell.isSetsidSupported(Shell.java:390)
[junit4] > at
org.apache.hadoop.util.Shell.<clinit>(Shell.java:380)
[junit4] > at
org.apache.hadoop.util.StringUtils.<clinit>(StringUtils.java:79)
[junit4] > at
org.apache.hadoop.conf.Configuration.getTrimmedStringCollection(Configuration.java:1747)
[junit4] > at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getStorageDirs(FSNamesystem.java:1407)
[junit4] > at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getNamespaceDirs(FSNamesystem.java:1388)
[junit4] > at
org.apache.hadoop.hdfs.MiniDFSCluster.createNameNodesAndSetConf(MiniDFSCluster.java:931)
[junit4] > at
org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:807)
[junit4] > at
org.apache.hadoop.hdfs.MiniDFSCluster.<init>(MiniDFSCluster.java:738)
[junit4] > at
org.apache.hadoop.hdfs.MiniDFSCluster.<init>(MiniDFSCluster.java:608)
[junit4] > at
org.apache.solr.cloud.hdfs.HdfsTestUtil.setupClass(HdfsTestUtil.java:81)
[junit4] > at
org.apache.solr.cloud.hdfs.HdfsTestUtil.setupClass(HdfsTestUtil.java:53)
[junit4] > at
org.apache.solr.cloud.hdfs.StressHdfsTest.setupClass(StressHdfsTest.java:64)
[junit4] > at java.lang.Thread.run(Thread.java:745)
[junit4] Completed on J1 in 1.43s, 0 tests, 1 error <<< FAILURES!
--------
[junit4] Suite: org.apache.solr.store.hdfs.HdfsLockFactoryTest
[junit4] 2> Creating dataDir:
/Users/steff/LiaceDisk/lucene_solr_5_1_0/solr/build/solr-core/test/J1/temp/solr.store.hdfs.HdfsLockFactoryTest
9A1D1C06EE13AC04-001/init-core-data-001
[junit4] 2> 1855736 T7001 oas.SolrTestCaseJ4.buildSSLConfig
Randomized ssl (true) and clientAuth (false)
[junit4] 2> 1855819 T7001 oas.SolrTestCaseJ4.deleteCore ###deleteCore
[junit4] 2> NOTE: test params are: codec=CheapBastard,
sim=DefaultSimilarity, locale=no_NO_NY, timezone=US/Indiana-Starke
[junit4] 2> NOTE: Mac OS X 10.10.2 x86_64/Oracle Corporation
1.8.0_25 (64-bit)/cpus=8,threads=1,free=94187552,total=457179136
[junit4] 2> NOTE: All tests run in this JVM: [HighlighterTest,
CoreMergeIndexesAdminHandlerTest, OpenCloseCoreStressTest,
FileUtilsTest, HdfsBasicDistributedZk2Test, TestExactSharedStatsCache,
DistributedQueryComponentCustomSortTest, TestCloudInspectUtil,
TestQuerySenderNoQuery, SimplePostToolTest, TestSchemaNameResource,
TestFieldCollectionResource, BasicFunctionalityTest,
TermVectorComponentDistributedTest, IndexBasedSpellCheckerTest,
LeaderElectionTest, TestRandomDVFaceting, ShowFileRequestHandlerTest,
TestReplicationHandler, InfoHandlerTest, DistributedQueueTest,
TestStressReorder, CursorPagingTest, ScriptEngineTest,
XmlUpdateRequestHandlerTest, ShardRoutingCustomTest,
ClusterStateUpdateTest, TestJsonRequest, TestBM25SimilarityFactory,
MigrateRouteKeyTest, RollingRestartTest, DocValuesTest, PolyFieldTest,
TestSimpleQParserPlugin, TimeZoneUtilsTest, ReplicationFactorTest,
TestJettySolrRunner, DistributedSuggestComponentTest, TestRTGBase,
TestBlobHandler, TestMaxScoreQueryParser, TestHashQParserPlugin,
CSVRequestHandlerTest, TestDocumentBuilder, SolrPluginUtilsTest,
DistributedFacetPivotSmallTest, TestManagedSchema, RecoveryZkTest,
HdfsBasicDistributedZkTest, SimpleCollectionCreateDeleteTest,
TestFastWriter, TestRequestStatusCollectionAPI, DistanceUnitsTest,
TestConfigSets, TestManagedResourceStorage, BadCopyFieldTest,
TestPartialUpdateDeduplication, TestCryptoKeys, MinimalSchemaTest,
SolrInfoMBeanTest, TestCursorMarkWithoutUniqueKey,
TestDistributedGrouping, TestGroupingSearch, TestHighlightDedupGrouping,
TestJoin, TestTolerantSearch, TestTrie,
PathHierarchyTokenizerFactoryTest, TestReversedWildcardFilterFactory,
ActionThrottleTest, AliasIntegrationTest, AssignTest,
BasicDistributedZk2Test, FullSolrCloudDistribCmdsTest,
LeaderInitiatedRecoveryOnCommitTest, OverseerTest,
SharedFSAutoReplicaFailoverUtilsTest, SliceStateTest, SyncSliceTest,
ZkNodePropsTest, HdfsChaosMonkeySafeLeaderTest,
HdfsCollectionsAPIDistributedZkTest, HdfsWriteToMultipleCollectionsTest,
StressHdfsTest, AlternateDirectoryTest, CachingDirectoryFactoryTest,
ResourceLoaderTest, SOLR749Test, TestArbitraryIndexDir,
TestCoreDiscovery, TestJmxIntegration, TestMergePolicyConfig,
TestShardHandlerFactory, TestSolrDeletionPolicy1, TestXIncludeConfig,
FieldAnalysisRequestHandlerTest, PingRequestHandlerTest,
TestConfigReload, XsltUpdateRequestHandlerTest, BadComponentTest,
DistributedExpandComponentTest,
DistributedQueryComponentOptimizationTest, TestRemoteStreaming,
TestPHPSerializedResponseWriter, TestSortingResponseWriter,
TestDefaultSearchFieldResource, TestFieldTypeResource,
TestSchemaSimilarityResource,
TestSolrQueryParserDefaultOperatorResource, CopyFieldTest,
DateFieldTest, DocValuesMissingTest, SpatialRPTFieldTypeTest,
TestSchemaManager, UUIDFieldTest, AnalyticsMergeStrategyTest,
AnalyticsQueryTest, MergeStrategyTest, QueryEqualityTest, RankQueryTest,
TestAddFieldRealTimeGet, TestComplexPhraseQParserPlugin, TestCustomSort,
TestElisionMultitermQuery, TestFiltering, TestRealTimeGet, TestSort,
TestStressVersions, TestSweetSpotSimilarityFactory, TestExactStatsCache,
FileBasedSpellCheckerTest, WordBreakSolrSpellCheckerTest, SuggesterTest,
TestAnalyzedSuggestions, TestPhraseSuggestions, BufferStoreTest,
HdfsLockFactoryTest]
[junit4] 2> NOTE: reproduce with: ant test
-Dtestcase=HdfsLockFactoryTest -Dtests.seed=9A1D1C06EE13AC04
-Dtests.slow=true -Dtests.locale=no_NO_NY
-Dtests.timezone=US/Indiana-Starke -Dtests.asserts=true
-Dtests.file.encoding=US-ASCII
[junit4] ERROR 0.00s J1 | HdfsLockFactoryTest (suite) <<<
[junit4] > Throwable #1: java.lang.NoClassDefFoundError: Could
not initialize class org.apache.hadoop.util.StringUtils
[junit4] > at
__randomizedtesting.SeedInfo.seed([9A1D1C06EE13AC04]:0)
[junit4] > at
org.apache.hadoop.conf.Configuration.getTrimmedStringCollection(Configuration.java:1747)
[junit4] > at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getStorageDirs(FSNamesystem.java:1407)
[junit4] > at
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getNamespaceDirs(FSNamesystem.java:1388)
[junit4] > at
org.apache.hadoop.hdfs.MiniDFSCluster.createNameNodesAndSetConf(MiniDFSCluster.java:931)
[junit4] > at
org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:807)
[junit4] > at
org.apache.hadoop.hdfs.MiniDFSCluster.<init>(MiniDFSCluster.java:738)
[junit4] > at
org.apache.hadoop.hdfs.MiniDFSCluster.<init>(MiniDFSCluster.java:608)
[junit4] > at
org.apache.solr.cloud.hdfs.HdfsTestUtil.setupClass(HdfsTestUtil.java:81)
[junit4] > at
org.apache.solr.cloud.hdfs.HdfsTestUtil.setupClass(HdfsTestUtil.java:53)
[junit4] > at
org.apache.solr.store.hdfs.HdfsLockFactoryTest.beforeClass(HdfsLockFactoryTest.java:45)
[junit4] > at java.lang.Thread.run(Thread.java:745)
[junit4] Completed on J1 in 0.13s, 0 tests, 1 error <<< FAILURES!
On 24/04/15 22:11, Dawid Weiss wrote:
> 1. does it fail when you run it via ant (ant build)?
> 2. the problem is very likely in dependencies declared in Maven (as
> compared to what the ivy dependencies are).
>
> Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Running 5.1.0 test-suite via maven
Posted by Dawid Weiss <da...@cs.put.poznan.pl>.
1. does it fail when you run it via ant (ant build)?
2. the problem is very likely in dependencies declared in Maven (as
compared to what the ivy dependencies are).
Dawid
On Fri, Apr 24, 2015 at 10:24 AM, Per Steffensen <st...@designware.dk> wrote:
> I have checked out tag lucene_solr_5_1_0 and try to run the test-suite using
> maven
> ant get-maven-poms
> cd maven-build/
> mvn -N -Pbootstrap -DskipTests install
> mvn -Dmaven.test.failure.ignore=true test
>
> The following tests fail running the test-suite this way using maven
> * SuggestFieldTest - all test methods fail
> * hadoop.MorphlineBasicMiniMRTest and hadoop.MorphlineGoLiveMiniMRTest -
> setupClass fails
> * TestCoreDiscovery.testCoreDirCantRead - test fails
>
> Now trying to run in Eclipse
> ant eclipse
> Open Eclipse and import project
> Running the failing tests
> * SuggestFieldTest - test passes
> * hadoop.MorphlineBasicMiniMRTest and hadoop.MorphlineGoLiveMiniMRTest -
> setupClass fails
> * TestCoreDiscovery.testCoreDirCantRead - test passes
>
> Can anyone explain this? Would expect a green test-suite for a released
> solr/lucene.
> What might be wrong with SuggestFieldTest and TestCoreDiscovery tests run
> through maven (fail), compared to run through Eclipse (pass)?
> Why does the Morphline tests fail (both maven and Eclipse)?
> It is the correct way to run tests using maven? It there another way the
> test-suite is usually run (e.g. using ant)?
>
> Thanks in advance.
>
> Regards, Per Steffensen
> ------------------------------------- fail stacktraces
> -----------------------------------
> * SuggestFieldTest fails using maven (not Eclipse) like this:
> java.lang.IllegalArgumentException: An SPI class of type
> org.apache.lucene.codecs.PostingsFormat with name 'completion' does not
> exist. You need to add the corresponding JAR file supporting this SPI to
> your classpath. The current classpath supports the following names:
> [MockRandom, RAMOnly, LuceneFixedGap, LuceneVarGapFixedInterval,
> LuceneVarGapDocFreqInterval, TestBloomFilteredLucenePostings, Asserting,
> Lucene50, BlockTreeOrds, BloomFilter, Direct, FSTOrd50, FST50, Memory,
> SimpleText]
> at org.apache.lucene.util.NamedSPILoader.lookup(NamedSPILoader.java:111)
> at
> org.apache.lucene.codecs.PostingsFormat.forName(PostingsFormat.java:100)
> at
> org.apache.lucene.codecs.perfield.PerFieldPostingsFormat$FieldsReader.<init>(PerFieldPostingsFormat.java:255)
> at
> org.apache.lucene.codecs.perfield.PerFieldPostingsFormat.fieldsProducer(PerFieldPostingsFormat.java:336)
> at
> org.apache.lucene.index.SegmentCoreReaders.<init>(SegmentCoreReaders.java:104)
> at org.apache.lucene.index.SegmentReader.<init>(SegmentReader.java:65)
> at
> org.apache.lucene.index.ReadersAndUpdates.getReader(ReadersAndUpdates.java:132)
> at
> org.apache.lucene.index.ReadersAndUpdates.getReadOnlyClone(ReadersAndUpdates.java:184)
> at
> org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:99)
> at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:429)
> at
> org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:343)
> at
> org.apache.lucene.index.RandomIndexWriter.getReader(RandomIndexWriter.java:280)
> at
> org.apache.lucene.search.suggest.document.SuggestFieldTest.testReturnedDocID(SuggestFieldTest.java:459)
>
> * The Morphline tests fail (both maven and Eclipse) like this:
> org.apache.hadoop.yarn.exceptions.YarnRuntimeException:
> java.lang.NoClassDefFoundError:
> org/apache/hadoop/yarn/server/applicationhistoryservice/ApplicationHistoryWriter
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at
> org.apache.hadoop.yarn.server.resourcemanager.ResourceManager.createRMApplicationHistoryWriter(ResourceManager.java:357)
> at
> org.apache.hadoop.yarn.server.resourcemanager.ResourceManager$RMActiveServices.serviceInit(ResourceManager.java:468)
> at
> org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
> at
> org.apache.hadoop.yarn.server.resourcemanager.ResourceManager.createAndInitActiveServices(ResourceManager.java:989)
> at
> org.apache.hadoop.yarn.server.resourcemanager.ResourceManager.serviceInit(ResourceManager.java:255)
> at
> org.apache.hadoop.service.AbstractService.init(AbstractService.java:163)
> at
> org.apache.solr.hadoop.hack.MiniYARNCluster$ResourceManagerWrapper.serviceStart(MiniYARNCluster.java:200)
> at
> org.apache.hadoop.service.AbstractService.start(AbstractService.java:193)
> at
> org.apache.hadoop.service.CompositeService.serviceStart(CompositeService.java:120)
> at
> org.apache.hadoop.service.AbstractService.start(AbstractService.java:193)
> at
> org.apache.solr.hadoop.hack.MiniMRClientClusterFactory.create(MiniMRClientClusterFactory.java:83)
> at
> org.apache.solr.hadoop.hack.MiniMRCluster.<init>(MiniMRCluster.java:191)
> at
> org.apache.solr.hadoop.hack.MiniMRCluster.<init>(MiniMRCluster.java:179)
> at
> org.apache.solr.hadoop.hack.MiniMRCluster.<init>(MiniMRCluster.java:171)
> at
> org.apache.solr.hadoop.MorphlineBasicMiniMRTest.setupClass(MorphlineBasicMiniMRTest.java:174)
>
> * TestCoreDiscovery.testCoreDirCantRead fails using maven (not Eclipse) like
> this:
> java.lang.AssertionError: null
> at
> __randomizedtesting.SeedInfo.seed([C815A145972F10FC:B5517513E8A8DE8E]:0)
> at org.junit.Assert.fail(Assert.java:92)
> at org.junit.Assert.assertTrue(Assert.java:43)
> at org.junit.Assert.assertNull(Assert.java:551)
> at org.junit.Assert.assertNull(Assert.java:562)
> at
> org.apache.solr.core.TestCoreDiscovery.testCoreDirCantRead(TestCoreDiscovery.java:286)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org