Re: JCC linux patch
Hi Caleb, On Tue, 2 Oct 2012, Caleb Burns wrote: On Tue, Oct 2, 2012 at 1:04 AM, Andi Vajda va...@apache.org wrote: Great. Now, in order to get the patch to me, you need to either: - open a bug in JIRA and attach it there (PYLUCENE project) - or send it to me directly I opened a bug on JIRA for PyLucene and added the patch: https://issues.apache.org/jira/browse/PYLUCENE-24 If you send patches to the list, they get eaten by the list processor. Sorry. I didn't realize attachments were filtered. I took a look at your patch. A couple of questions: - In jcc/helpers/linux.py, you seem to be getting rid of the 0.6.15 setuptools case. How is that version handled now ? I remember adding this case last May since it's a version out there in the wild and patching it failed as it needs the 0.6c7 patch. Am I reading this correctly that you're assuming 0.6.15 to be compatible with 0.6.1 distribute ? - You have a line of new code in linux.py that says: +if build_ext.use_stubs or os.name == 'nt': How can os.name be 'nt' when linux.py is being run ? Andi..
[JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 56 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/56/ 2 tests failed. REGRESSION: org.apache.lucene.index.Test2BPostings.test Error Message: background merge hit exception: _0(5.0):C10063430 _1(5.0):C10063430 _2(5.0):C10063430 _3(5.0):C10063430 _4(5.0):C10063430 _5(5.0):C10063430 _6(5.0):C10063430 _7(5.0):C10063430 _8(5.0):C2088085 into _9 [maxNumSegments=1] Stack Trace: java.io.IOException: background merge hit exception: _0(5.0):C10063430 _1(5.0):C10063430 _2(5.0):C10063430 _3(5.0):C10063430 _4(5.0):C10063430 _5(5.0):C10063430 _6(5.0):C10063430 _7(5.0):C10063430 _8(5.0):C2088085 into _9 [maxNumSegments=1] at __randomizedtesting.SeedInfo.seed([7A651D74329400BD:F23122AE9C686D45]:0) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1644) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1580) at org.apache.lucene.index.Test2BPostings.test(Test2BPostings.java:81) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:679) Caused by: java.lang.OutOfMemoryError: Java heap space at org.apache.lucene.store.RAMFile.newBuffer(RAMFile.java:75) at
[jira] [Updated] (SOLR-3919) Problem with hl.mergeContinuous - snippet is too long but only one hit
[ https://issues.apache.org/jira/browse/SOLR-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yoni Amir updated SOLR-3919: Description: I am using a configuration roughly as follows: bool name=hl.usePhraseHighlightertrue/bool bool name=hl.highlightMultiTermtrue/bool int name=hl.snippets4/int bool name=hl.mergeContiguoustrue/bool I found a strange case as follows: I have only one hit in the field, so I expect that no merging will take place. However, solr returns a highlight snippet of length 400. In effect, it calculates the hl.snippet size times 100. With hl.snippet=10, the length is 1000. I think it is because hl.fragsize is 100 by default. This occurs only if the hit is sufficiently close to the beginning of the field's text - that is, if it is between the 300th and 400th character. In that change, the first four 100-block size snippets are merged as if all of them have a hit. This behavior is wrong, and if there is only one hit, I don't expect solr to merge anything for me. was: I am using a configuration roughly as follows: bool name=hl.usePhraseHighlightertrue/bool bool name=hl.highlightMultiTermtrue/bool int name=hl.snippets4/int bool name=hl.mergeContiguoustrue/bool I found a strange case as follows: I have only 1 hit in the field, so I expect that no merging will take place. However, solr returns a highlight snippet of length 400. In effect, it calculates the hl.snippet size times 100. With hl.snippet=10, the length is 1000. I think it is because hl.fragsize is 100 by default. This occurs only if the hit is sufficiently close to the beginning of the field's text - that is, if it is between the 300th and 400th character. In that change, the first four 100-block size snippets are merged as if all of them have a hit. This behavior is wrong, and if there is only one hit, I don't expect solr to merge anything for me. Problem with hl.mergeContinuous - snippet is too long but only one hit -- Key: SOLR-3919 URL: https://issues.apache.org/jira/browse/SOLR-3919 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 4.0-BETA Environment: win xp, java 7 Reporter: Yoni Amir I am using a configuration roughly as follows: bool name=hl.usePhraseHighlightertrue/bool bool name=hl.highlightMultiTermtrue/bool int name=hl.snippets4/int bool name=hl.mergeContiguoustrue/bool I found a strange case as follows: I have only one hit in the field, so I expect that no merging will take place. However, solr returns a highlight snippet of length 400. In effect, it calculates the hl.snippet size times 100. With hl.snippet=10, the length is 1000. I think it is because hl.fragsize is 100 by default. This occurs only if the hit is sufficiently close to the beginning of the field's text - that is, if it is between the 300th and 400th character. In that change, the first four 100-block size snippets are merged as if all of them have a hit. This behavior is wrong, and if there is only one hit, I don't expect solr to merge anything for me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3919) Problem with hl.mergeContinuous - snippet is too long but only one hit
[ https://issues.apache.org/jira/browse/SOLR-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yoni Amir updated SOLR-3919: Summary: Problem with hl.mergeContinuous - snippet is too long but only one hit (was: Problem with hl.mergeContinuous - sniipt is too long but only one hit) Problem with hl.mergeContinuous - snippet is too long but only one hit -- Key: SOLR-3919 URL: https://issues.apache.org/jira/browse/SOLR-3919 Project: Solr Issue Type: Bug Components: highlighter Affects Versions: 4.0-BETA Environment: win xp, java 7 Reporter: Yoni Amir I am using a configuration roughly as follows: bool name=hl.usePhraseHighlightertrue/bool bool name=hl.highlightMultiTermtrue/bool int name=hl.snippets4/int bool name=hl.mergeContiguoustrue/bool I found a strange case as follows: I have only 1 hit in the field, so I expect that no merging will take place. However, solr returns a highlight snippet of length 400. In effect, it calculates the hl.snippet size times 100. With hl.snippet=10, the length is 1000. I think it is because hl.fragsize is 100 by default. This occurs only if the hit is sufficiently close to the beginning of the field's text - that is, if it is between the 300th and 400th character. In that change, the first four 100-block size snippets are merged as if all of them have a hit. This behavior is wrong, and if there is only one hit, I don't expect solr to merge anything for me. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 56 - Failure
Hmmm OOME w/ Test2BPostings ... It doesn't reproduce standalone, but does reproduce if I run all tests w/ 2 JVMs (test leak somewhere?)... I'll get a heap dump and look. Mike McCandless http://blog.mikemccandless.com On Sun, Oct 7, 2012 at 3:36 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/56/ 2 tests failed. REGRESSION: org.apache.lucene.index.Test2BPostings.test Error Message: background merge hit exception: _0(5.0):C10063430 _1(5.0):C10063430 _2(5.0):C10063430 _3(5.0):C10063430 _4(5.0):C10063430 _5(5.0):C10063430 _6(5.0):C10063430 _7(5.0):C10063430 _8(5.0):C2088085 into _9 [maxNumSegments=1] Stack Trace: java.io.IOException: background merge hit exception: _0(5.0):C10063430 _1(5.0):C10063430 _2(5.0):C10063430 _3(5.0):C10063430 _4(5.0):C10063430 _5(5.0):C10063430 _6(5.0):C10063430 _7(5.0):C10063430 _8(5.0):C2088085 into _9 [maxNumSegments=1] at __randomizedtesting.SeedInfo.seed([7A651D74329400BD:F23122AE9C686D45]:0) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1644) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1580) at org.apache.lucene.index.Test2BPostings.test(Test2BPostings.java:81) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at
[jira] [Commented] (SOLR-3740) ExtendedDismaxQParser (edismax) does not obey q.op for parenthesized sub-queries
[
https://issues.apache.org/jira/browse/SOLR-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471280#comment-13471280
]
Michael Krkoska commented on SOLR-3740:
---
I ran into this issue with a simple query like ID100, which gets rewritten by
a WordDelimiterFilter in my config into (text:ID text:100). Unfortunately my
q.op=AND is not passed on to the underlying query parser, which results in a
OR, as that's the default.
Adding
{code:java}
up.setDefaultOperator(QueryParsing.getQueryParserDefaultOperator(req.getSchema(),
solrParams.get(QueryParsing.OP)));
{code}
in line 193 of ExtendedDismaxQParserPlugin fixes the bug for me and seems
sensible.
Please look into this before 4.0 release, as it seems to be a rather serious
bug.
ExtendedDismaxQParser (edismax) does not obey q.op for parenthesized
sub-queries
Key: SOLR-3740
URL: https://issues.apache.org/jira/browse/SOLR-3740
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 3.6.1, 4.0-BETA
Reporter: Jack Krupansky
For a query such as cat dog (fox bat fish) with q.op=AND, the default
query operator is only set to AND for the top-level query, and not for the
parenthesize sub-query. This is not documented behavior and rather surprising.
This happens because edismax only simulates the default operator by forcing
mm (minMatch) to 100% for the top-level BooleanQuery alone and never sets
the default query operator when it invokes the classic Lucene Query parser
which in turn is performing parsing and query generation for the
parenthesized sub-query.
One solution is for edismax to always set the default query operator when
calling the classic Lucene query parser, or at least when q.op=AND.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3740) ExtendedDismaxQParser (edismax) does not obey q.op for parenthesized sub-queries
[ https://issues.apache.org/jira/browse/SOLR-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471287#comment-13471287 ] Yonik Seeley commented on SOLR-3740: bq. I ran into this issue with a simple query like ID100, which gets rewritten by a WordDelimiterFilter in my config into (text:ID text:100). In this specific case, you may want autoGeneratePhraseQueries=true set on your field type so that any split tokens end up acting like a phrase query of ID 100. ExtendedDismaxQParser (edismax) does not obey q.op for parenthesized sub-queries Key: SOLR-3740 URL: https://issues.apache.org/jira/browse/SOLR-3740 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 3.6.1, 4.0-BETA Reporter: Jack Krupansky For a query such as cat dog (fox bat fish) with q.op=AND, the default query operator is only set to AND for the top-level query, and not for the parenthesize sub-query. This is not documented behavior and rather surprising. This happens because edismax only simulates the default operator by forcing mm (minMatch) to 100% for the top-level BooleanQuery alone and never sets the default query operator when it invokes the classic Lucene Query parser which in turn is performing parsing and query generation for the parenthesized sub-query. One solution is for edismax to always set the default query operator when calling the classic Lucene query parser, or at least when q.op=AND. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3740) ExtendedDismaxQParser (edismax) does not obey q.op for parenthesized sub-queries
[ https://issues.apache.org/jira/browse/SOLR-3740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471290#comment-13471290 ] Michael Krkoska commented on SOLR-3740: --- bq. In this specific case, you may want autoGeneratePhraseQueries=true set on your field type so that any split tokens end up acting like a phrase query of ID 100. Thanks, that's indeed useful! But while it is a workaround for some cases of the bug, I still see the issue as something serious. ExtendedDismaxQParser (edismax) does not obey q.op for parenthesized sub-queries Key: SOLR-3740 URL: https://issues.apache.org/jira/browse/SOLR-3740 Project: Solr Issue Type: Bug Components: query parsers Affects Versions: 3.6.1, 4.0-BETA Reporter: Jack Krupansky For a query such as cat dog (fox bat fish) with q.op=AND, the default query operator is only set to AND for the top-level query, and not for the parenthesize sub-query. This is not documented behavior and rather surprising. This happens because edismax only simulates the default operator by forcing mm (minMatch) to 100% for the top-level BooleanQuery alone and never sets the default query operator when it invokes the classic Lucene Query parser which in turn is performing parsing and query generation for the parenthesized sub-query. One solution is for edismax to always set the default query operator when calling the classic Lucene query parser, or at least when q.op=AND. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Build failed in Jenkins: slow-io-beasting #3752
See http://sierranevada.servebeer.com:8080/job/slow-io-beasting/3752/ -- [...truncated 3070 lines...] [junit4:junit4] OK 0.02s J1 | TestIndexInput.testRawIndexInputRead [junit4:junit4] OK 0.03s J1 | TestIndexInput.testBufferedIndexInputRead [junit4:junit4] OK 0.02s J1 | TestIndexInput.testByteArrayDataInput [junit4:junit4] Completed on J1 in 0.31s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestCrash [junit4:junit4] 1 TEST: initIndex [junit4:junit4] 1 TEST: done initIndex [junit4:junit4] 1 TEST: now crash [junit4:junit4] OK 0.05s J2 | TestCrash.testWriterAfterCrash [junit4:junit4] OK 0.36s J2 | TestCrash.testCrashWhileIndexing [junit4:junit4] OK 0.17s J2 | TestCrash.testCrashAfterReopen [junit4:junit4] OK 0.03s J2 | TestCrash.testCrashAfterClose [junit4:junit4] OK 0.14s J2 | TestCrash.testCrashAfterCloseNoWait [junit4:junit4] Completed on J2 in 0.95s, 5 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestSegmentTermDocs [junit4:junit4] OK 0.13s J0 | TestSegmentTermDocs.testTermDocs [junit4:junit4] OK 0.11s J0 | TestSegmentTermDocs.testSkipTo [junit4:junit4] OK 0.47s J0 | TestSegmentTermDocs.testIndexDivisor [junit4:junit4] OK 0.11s J0 | TestSegmentTermDocs.test [junit4:junit4] OK 0.17s J0 | TestSegmentTermDocs.testBadSeek [junit4:junit4] Completed on J0 in 1.02s, 5 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestOmitTf [junit4:junit4] OK 0.02s J2 | TestOmitTf.testMixedRAM [junit4:junit4] OK 0.05s J2 | TestOmitTf.testBasic [junit4:junit4] OK 0.00s J2 | TestOmitTf.testStats [junit4:junit4] OK 0.10s J2 | TestOmitTf.testNoPrxFile [junit4:junit4] OK 0.09s J2 | TestOmitTf.testMixedMerge [junit4:junit4] OK 0.02s J2 | TestOmitTf.testOmitTermFreqAndPositions [junit4:junit4] Completed on J2 in 0.28s, 6 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestDocumentWriter [junit4:junit4] OK 0.00s J2 | TestDocumentWriter.testTokenReuse [junit4:junit4] OK 0.00s J2 | TestDocumentWriter.testPreAnalyzedField [junit4:junit4] OK 0.00s J2 | TestDocumentWriter.testMixedTermVectorSettingsSameField [junit4:junit4] OK 0.11s J2 | TestDocumentWriter.testAddDocument [junit4:junit4] OK 0.00s J2 | TestDocumentWriter.test [junit4:junit4] OK 0.00s J2 | TestDocumentWriter.testPositionIncrementGap [junit4:junit4] OK 0.00s J2 | TestDocumentWriter.testLUCENE_1590 [junit4:junit4] Completed on J2 in 0.17s, 7 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestParallelCompositeReader [junit4:junit4] OK 0.19s J1 | TestParallelCompositeReader.testQueriesCompositeComposite [junit4:junit4] OK 0.34s J1 | TestParallelCompositeReader.testRefCounts1 [junit4:junit4] OK 0.14s J1 | TestParallelCompositeReader.testIncompatibleIndexes1 [junit4:junit4] OK 0.02s J1 | TestParallelCompositeReader.testRefCounts2 [junit4:junit4] OK 0.11s J1 | TestParallelCompositeReader.testQueries [junit4:junit4] OK 0.19s J1 | TestParallelCompositeReader.testIncompatibleIndexes2 [junit4:junit4] OK 0.15s J1 | TestParallelCompositeReader.testIncompatibleIndexes3 [junit4:junit4] OK 0.08s J1 | TestParallelCompositeReader.testIgnoreStoredFields [junit4:junit4] Completed on J1 in 1.34s, 8 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestPrefixCodedTerms [junit4:junit4] OK 0.00s J2 | TestPrefixCodedTerms.testMergeOne [junit4:junit4] OK 0.00s J2 | TestPrefixCodedTerms.testEmpty [junit4:junit4] OK 0.06s J2 | TestPrefixCodedTerms.testRandom [junit4:junit4] OK 0.17s J2 | TestPrefixCodedTerms.testMergeRandom [junit4:junit4] OK 0.00s J2 | TestPrefixCodedTerms.testMergeEmpty [junit4:junit4] OK 0.00s J2 | TestPrefixCodedTerms.testOne [junit4:junit4] Completed on J2 in 0.25s, 6 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestDocsAndPositions [junit4:junit4] OK 0.06s J1 | TestDocsAndPositions.testLargeNumberOfPositions [junit4:junit4] OK 0.06s J1 | TestDocsAndPositions.testDocsAndPositionsEnumStart [junit4:junit4] OK 0.02s J1 | TestDocsAndPositions.testRandomPositions [junit4:junit4] OK 0.00s J1 | TestDocsAndPositions.testPositionsSimple [junit4:junit4] OK 0.00s J1 | TestDocsAndPositions.testDocsEnumStart [junit4:junit4] OK 0.05s J1 | TestDocsAndPositions.testRandomDocs [junit4:junit4] Completed on J1 in 0.22s, 6 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestForTooMuchCloning [junit4:junit4] OK 0.06s J2 | TestForTooMuchCloning.test [junit4:junit4] Completed on J2 in 0.08s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestIndexableField [junit4:junit4] OK 0.14s J2 | TestIndexableField.testArbitraryFields [junit4:junit4] Completed on J2 in 0.16s, 1 test [junit4:junit4] [junit4:junit4]
Jenkins build is back to normal : slow-io-beasting #3753
See http://sierranevada.servebeer.com:8080/job/slow-io-beasting/3753/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.6.0_35) - Build # 1081 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/1081/ Java: 64bit/jdk1.6.0_35 -XX:+UseParallelGC All tests passed Build Log: [...truncated 26371 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:352: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:65: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build.xml:503: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\common-build.xml:1910: Can't get https://issues.apache.org/jira/rest/api/2/project/SOLR to C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\docs\changes\jiraVersionList.json Total time: 62 minutes 36 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 64bit/jdk1.6.0_35 -XX:+UseParallelGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 56 - Failure
I committed a fix. Mike McCandless http://blog.mikemccandless.com On Sun, Oct 7, 2012 at 11:55 AM, Michael McCandless luc...@mikemccandless.com wrote: Hmmm OOME w/ Test2BPostings ... It doesn't reproduce standalone, but does reproduce if I run all tests w/ 2 JVMs (test leak somewhere?)... I'll get a heap dump and look. Mike McCandless http://blog.mikemccandless.com On Sun, Oct 7, 2012 at 3:36 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/56/ 2 tests failed. REGRESSION: org.apache.lucene.index.Test2BPostings.test Error Message: background merge hit exception: _0(5.0):C10063430 _1(5.0):C10063430 _2(5.0):C10063430 _3(5.0):C10063430 _4(5.0):C10063430 _5(5.0):C10063430 _6(5.0):C10063430 _7(5.0):C10063430 _8(5.0):C2088085 into _9 [maxNumSegments=1] Stack Trace: java.io.IOException: background merge hit exception: _0(5.0):C10063430 _1(5.0):C10063430 _2(5.0):C10063430 _3(5.0):C10063430 _4(5.0):C10063430 _5(5.0):C10063430 _6(5.0):C10063430 _7(5.0):C10063430 _8(5.0):C2088085 into _9 [maxNumSegments=1] at __randomizedtesting.SeedInfo.seed([7A651D74329400BD:F23122AE9C686D45]:0) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1644) at org.apache.lucene.index.IndexWriter.forceMerge(IndexWriter.java:1580) at org.apache.lucene.index.Test2BPostings.test(Test2BPostings.java:81) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at
Re: Build failed in Jenkins: slow-io-beasting #3090
I couldn't repro after much beasting ... but I committed a possible fix. Mike McCandless http://blog.mikemccandless.com On Sun, Oct 7, 2012 at 1:37 AM, hudsonsevilt...@gmail.com wrote: See http://sierranevada.servebeer.com:8080/job/slow-io-beasting/3090/ -- [...truncated 2472 lines...] [junit4:junit4] OK 0.02s J0 | TestCompoundFile.testSingleFile [junit4:junit4] Completed on J0 in 3.06s, 18 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestNRTReaderWithThreads [junit4:junit4] OK 1.56s J2 | TestNRTReaderWithThreads.testIndexing [junit4:junit4] Completed on J2 in 1.57s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestCrashCausesCorruptIndex [junit4:junit4] OK 0.22s J2 | TestCrashCausesCorruptIndex.testCrashCorruptsIndexing [junit4:junit4] Completed on J2 in 0.27s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestConcurrentMergeScheduler [junit4:junit4] OK 0.25s J1 | TestConcurrentMergeScheduler.testDeleteMerging [junit4:junit4] OK 0.48s J1 | TestConcurrentMergeScheduler.testNoWaitClose [junit4:junit4] OK 0.38s J1 | TestConcurrentMergeScheduler.testNoExtraFiles [junit4:junit4] OK 0.09s J1 | TestConcurrentMergeScheduler.testFlushExceptions [junit4:junit4] Completed on J1 in 1.21s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestStressAdvance [junit4:junit4] OK 0.39s J2 | TestStressAdvance.testStressAdvance [junit4:junit4] Completed on J2 in 0.41s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.Test2BDocs [junit4:junit4] OK 0.00s J3 | Test2BDocs.testOverflow [junit4:junit4] OK 0.62s J3 | Test2BDocs.testExactlyAtLimit [junit4:junit4] Completed on J3 in 1.26s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestConsistentFieldNumbers [junit4:junit4] OK 0.08s J0 | TestConsistentFieldNumbers.testAddIndexes [junit4:junit4] OK 0.06s J0 | TestConsistentFieldNumbers.testSameFieldNumbersAcrossSegments [junit4:junit4] OK 0.05s J0 | TestConsistentFieldNumbers.testManyFields [junit4:junit4] OK 0.86s J0 | TestConsistentFieldNumbers.testFieldNumberGaps [junit4:junit4] Completed on J0 in 1.06s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestRollingUpdates [junit4:junit4] OK 0.94s J1 | TestRollingUpdates.testUpdateSameDoc [junit4:junit4] OK 0.23s J1 | TestRollingUpdates.testRollingUpdates [junit4:junit4] Completed on J1 in 1.18s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestIndexWriterOnDiskFull [junit4:junit4] OK 0.03s J0 | TestIndexWriterOnDiskFull.testAddDocumentOnDiskFull [junit4:junit4] OK 0.00s J0 | TestIndexWriterOnDiskFull.testImmediateDiskFull [junit4:junit4] OK 0.03s J0 | TestIndexWriterOnDiskFull.testCorruptionAfterDiskFullDuringMerge [junit4:junit4] OK 0.54s J0 | TestIndexWriterOnDiskFull.testAddIndexOnDiskFull [junit4:junit4] Completed on J0 in 0.62s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestSegmentReader [junit4:junit4] OK 0.13s J2 | TestSegmentReader.test [junit4:junit4] OK 0.19s J2 | TestSegmentReader.testDocument [junit4:junit4] OK 0.11s J2 | TestSegmentReader.testGetFieldNameVariations [junit4:junit4] OK 0.26s J2 | TestSegmentReader.testTerms [junit4:junit4] OK 0.11s J2 | TestSegmentReader.testNorms [junit4:junit4] OK 0.11s J2 | TestSegmentReader.testTermVectors [junit4:junit4] Completed on J2 in 0.95s, 6 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestMaxTermFrequency [junit4:junit4] OK 0.36s J0 | TestMaxTermFrequency.test [junit4:junit4] Completed on J0 in 0.37s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestStressIndexing2 [junit4:junit4] OK 0.30s J1 | TestStressIndexing2.testMultiConfig [junit4:junit4] OK 0.11s J1 | TestStressIndexing2.testRandomIWReader [junit4:junit4] OK 0.11s J1 | TestStressIndexing2.testRandom [junit4:junit4] Completed on J1 in 0.52s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestCodecs [junit4:junit4] OK 0.00s J3 | TestCodecs.testFixedPostings [junit4:junit4] OK 0.02s J3 | TestCodecs.testSepPositionAfterMerge [junit4:junit4] OK 1.40s J3 | TestCodecs.testRandomPostings [junit4:junit4] Completed on J3 in 1.43s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestCrash [junit4:junit4] OK 0.06s J2 | TestCrash.testCrashAfterClose [junit4:junit4] OK 0.20s J2 | TestCrash.testCrashAfterCloseNoWait [junit4:junit4] OK 0.03s J2 | TestCrash.testCrashWhileIndexing [junit4:junit4] 1 TEST: initIndex [junit4:junit4] 1 TEST: done initIndex [junit4:junit4] 1 TEST: now crash [junit4:junit4] OK 0.11s J2 |
RE: VOTE: release 4.0 (RC2)
+1 The smoke tester succeeded for me on Win7+Cygwin and on OS X 10.8.2, using Oracle Java 1.6.0_35 and 1.7.0_07 on both OSs. Steve -Original Message- From: Robert Muir [mailto:rcm...@gmail.com] Sent: Saturday, October 06, 2012 4:11 AM To: dev@lucene.apache.org Subject: VOTE: release 4.0 (RC2) artifacts here: http://s.apache.org/lusolr40rc2 Thanks for the good inspection of rc#1 and finding bugs, which found test bugs and other bugs! I am happy this was all discovered and sorted out before release. vote stays open until wednesday, the weekend is just extra time for evaluating the RC. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-1822) FastVectorHighlighter: SimpleFragListBuilder hard-coded 6 char margin is too naive
[ https://issues.apache.org/jira/browse/LUCENE-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated LUCENE-1822: --- Attachment: LUCENE-1822.patch Thank you for updating tests, Arcadius! I'll commit tomorrow if no one objects. FastVectorHighlighter: SimpleFragListBuilder hard-coded 6 char margin is too naive -- Key: LUCENE-1822 URL: https://issues.apache.org/jira/browse/LUCENE-1822 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Affects Versions: 2.9 Environment: any Reporter: Alex Vigdor Assignee: Koji Sekiguchi Priority: Minor Attachments: LUCENE-1822.patch, LUCENE-1822.patch, LUCENE-1822.patch, LUCENE-1822-tests.patch The new FastVectorHighlighter performs extremely well, however I've found in testing that the window of text chosen per fragment is often very poor, as it is hard coded in SimpleFragListBuilder to always select starting 6 characters to the left of the first phrase match in a fragment. When selecting long fragments, this often means that there is barely any context before the highlighted word, and lots after; even worse, when highlighting a phrase at the end of a short text the beginning is cut off, even though the entire phrase would fit in the specified fragCharSize. For example, highlighting Punishment in Crime and Punishment returns e and bPunishment/b no matter what fragCharSize is specified. I am going to attach a patch that improves the text window selection by recalculating the starting margin once all phrases in the fragment have been identified - this way if a single word is matched in a fragment, it will appear in the middle of the highlight, instead of 6 characters from the beginning. This way one can also guarantee that the entirety of short texts are represented in a fragment by specifying a large enough fragCharSize. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_07) - Build # 1084 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/1084/ Java: 64bit/jdk1.7.0_07 -XX:+UseG1GC All tests passed Build Log: [...truncated 27369 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\build.xml:245: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:552: Unable to delete file C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\lucene\build\analysis\common\lucene-analyzers-common-5.0-SNAPSHOT.jar Total time: 57 minutes 2 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 64bit/jdk1.7.0_07 -XX:+UseG1GC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: release 4.0 (RC2)
Success for smoke tester on my Windows 7 Cygwin machine. with Java 1.6.0_29. -- Jack Krupansky -Original Message- From: Robert Muir Sent: Saturday, October 06, 2012 4:10 AM To: dev@lucene.apache.org Subject: VOTE: release 4.0 (RC2) artifacts here: http://s.apache.org/lusolr40rc2 Thanks for the good inspection of rc#1 and finding bugs, which found test bugs and other bugs! I am happy this was all discovered and sorted out before release. vote stays open until wednesday, the weekend is just extra time for evaluating the RC. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_07) - Build # 1607 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/1607/ Java: 32bit/jdk1.7.0_07 -client -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.lucene.analysis.core.TestRandomChains.testRandomChains Error Message: startOffset must be non-negative, and endOffset must be = startOffset, startOffset=8,endOffset=6 Stack Trace: java.lang.IllegalArgumentException: startOffset must be non-negative, and endOffset must be = startOffset, startOffset=8,endOffset=6 at __randomizedtesting.SeedInfo.seed([F0E21C9495465AFA:CD0335F5D254473A]:0) at org.apache.lucene.analysis.tokenattributes.OffsetAttributeImpl.setOffset(OffsetAttributeImpl.java:43) at org.apache.lucene.analysis.shingle.ShingleFilter.incrementToken(ShingleFilter.java:323) at org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:78) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:632) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:542) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:443) at org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:859) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at
