[GitHub] [lucene-solr] dsmiley commented on a change in pull request #633: LUCENE-8753 UniformSplit PostingsFormat
dsmiley commented on a change in pull request #633: LUCENE-8753 UniformSplit
PostingsFormat
URL: https://github.com/apache/lucene-solr/pull/633#discussion_r294132381
##
File path:
lucene/codecs/src/java/org/apache/lucene/codecs/uniformsplit/IntersectBlockReader.java
##
@@ -291,23 +293,263 @@ public void seekExact(BytesRef term, TermState state) {
throw new UnsupportedOperationException();
}
- //TODO this approach is a hack to reuse complex code in AutomatonTermsEnum.
How to make ATE's logic more reusable?
- protected static class AutomatonNextTermCalculator extends
AutomatonTermsEnum {
+ //This is a copy of AutomatonTermsEnum. Since it's an inner class, the
outer class can
Review comment:
@jpountz as you asked, I forked AutomatonTermsEnum into UniformSplit's
IntersectBlockReader, and undid the minor change in ATE.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13347) Error writing Transaction log for UUIDField
[ https://issues.apache.org/jira/browse/SOLR-13347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865235#comment-16865235 ] Noble Paul commented on SOLR-13347: --- bq. then this sounds like an enhancement then. We could move it to "enhancements". I'm fine with it > Error writing Transaction log for UUIDField > --- > > Key: SOLR-13347 > URL: https://issues.apache.org/jira/browse/SOLR-13347 > Project: Solr > Issue Type: Bug > Components: Server >Affects Versions: 7.7, 7.7.1, 8.0 >Reporter: Thomas Wöckinger >Assignee: Noble Paul >Priority: Major > Labels: pull-request-available, ready-to-commit, test > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13347.patch > > Time Spent: 4h > Remaining Estimate: 0h > > When using Atomic Update, adding a value leads to following Exception > org.apache.solr.common.SolrException: TransactionLog doesn't know how to > serialize class java.util.UUID; try implementing ObjectResolver? > at > org.apache.solr.update.TransactionLog$1.resolve(TransactionLog.java:100) > at > org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:263) > at > org.apache.solr.common.util.JavaBinCodec.writeArray(JavaBinCodec.java:770) > at > org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:369) > at > org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:362) > at > org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:252) > at > org.apache.solr.common.util.JavaBinCodec$BinEntryWriter.put(JavaBinCodec.java:437) > at > org.apache.solr.common.MapWriter$EntryWriter.putNoEx(MapWriter.java:100) > at > org.apache.solr.common.MapWriter$EntryWriter.lambda$getBiConsumer$0(MapWriter.java:160) > at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:684) > at > org.apache.solr.common.SolrInputDocument.writeMap(SolrInputDocument.java:51) > at > org.apache.solr.common.util.JavaBinCodec.writeSolrInputDocument(JavaBinCodec.java:657) > at org.apache.solr.update.TransactionLog.write(TransactionLog.java:371) > at org.apache.solr.update.UpdateLog.add(UpdateLog.java:573) > at org.apache.solr.update.UpdateLog.add(UpdateLog.java:552) > at > org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:351) > at > org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:289) > at > org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:236) > at > org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:76) > at > org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:995) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1216) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:700) > at > org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103) > at > org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:327) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280) > at > org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:335) > at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235) > at > org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:300) > at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280) > at > org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:193) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:126) > at > org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:123) > at > org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:70) > at > org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:97) > at > org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68) > at >
[jira] [Comment Edited] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865229#comment-16865229 ] Marcus Eagan edited comment on SOLR-13537 at 6/17/19 1:37 AM: -- [~elyograg] I was using the Solr artifact/Solr builds so I put it in the Solr Jira. I've now added the Lucene artifact. So would it be appropriate for either, or default to Lucene? More committers in the future could be using GitHub a lot more. That is a reasonable assumption that I made but it could turn out to be false. One of my initial motivations was to inspire others to dig into why things were red. I do not think there's any reputation problem at risk here. Many projects are often red. There have been instances, though infrequently, where Lucene did not compile. Those builds would have been red, but usually Solr is green. It's almost always green for that task. Perfect world the tests pass when they should and fail when they should not. was (Author: marcussorealheis): [~elyograg] I was using the Solr artifact so I put it in the Solr Jira. I've now added the Lucene artifact. So would it be appropriate for either, or default to Lucene? More committers in the future could be using GitHub a lot more. That is a reasonable assumption that I made. One of my initial motivations was to inspire others to dig into why things were red. I do not think there's any reputation problem at risk here. Many projects are often red. There have been instances, though infrequently, where Lucene did not compile. Those builds would have been red, but usually Solr is green. It's almost always green for that task. Perfect world the tests pass when they should and fail when they should not. > Build Status Badge in git README > > > Key: SOLR-13537 > URL: https://issues.apache.org/jira/browse/SOLR-13537 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (9.0), 8.2 >Reporter: Marcus Eagan >Priority: Trivial > Attachments: Markdown Preview Of Build Status README.png, Simple > Artifact Build Badge.png, Simple Artifact Build Badges.png > > Time Spent: 10m > Remaining Estimate: 0h > > In order to aid developers and DevOps engineers who are working in a > git-driven ecosystem, it would be helpful to see the status builds in the > README. This is a standard for many open source projects. I think one could > debate whether we should have a multi-line build badge visual in the README > because people need to know about the builds for various versions and > platforms in the case of Lucene/Solr because it is such a large and widely > used project, in a variety of environments. The badges not only celebrate > that fact, they support its persistence in the future with new developers who > look for such information instictively. > I would recommend the active build pipelines (currently 8.x and 9.x) for each > platform, Linux, Windows, MacOSX, and Solaris. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865229#comment-16865229 ] Marcus Eagan commented on SOLR-13537: - [~elyograg] I was using the Solr artifact so I put it in the Solr Jira. I've now added the Lucene artifact. So would it be appropriate for either, or default to Lucene? More committers in the future could be using GitHub a lot more. That is a reasonable assumption that I made. One of my initial motivations was to inspire others to dig into why things were red. I do not think there's any reputation problem at risk here. Many projects are often red. There have been instances, though infrequently, where Lucene did not compile. Those builds would have been red, but usually Solr is green. It's almost always green for that task. Perfect world the tests pass when they should and fail when they should not. > Build Status Badge in git README > > > Key: SOLR-13537 > URL: https://issues.apache.org/jira/browse/SOLR-13537 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (9.0), 8.2 >Reporter: Marcus Eagan >Priority: Trivial > Attachments: Markdown Preview Of Build Status README.png, Simple > Artifact Build Badge.png, Simple Artifact Build Badges.png > > Time Spent: 10m > Remaining Estimate: 0h > > In order to aid developers and DevOps engineers who are working in a > git-driven ecosystem, it would be helpful to see the status builds in the > README. This is a standard for many open source projects. I think one could > debate whether we should have a multi-line build badge visual in the README > because people need to know about the builds for various versions and > platforms in the case of Lucene/Solr because it is such a large and widely > used project, in a variety of environments. The badges not only celebrate > that fact, they support its persistence in the future with new developers who > look for such information instictively. > I would recommend the active build pipelines (currently 8.x and 9.x) for each > platform, Linux, Windows, MacOSX, and Solaris. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13537) Build Status Badge in git README
[ https://issues.apache.org/jira/browse/SOLR-13537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eagan updated SOLR-13537: Attachment: Simple Artifact Build Badges.png > Build Status Badge in git README > > > Key: SOLR-13537 > URL: https://issues.apache.org/jira/browse/SOLR-13537 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Build, documentation >Affects Versions: master (9.0), 8.2 >Reporter: Marcus Eagan >Priority: Trivial > Attachments: Markdown Preview Of Build Status README.png, Simple > Artifact Build Badge.png, Simple Artifact Build Badges.png > > Time Spent: 10m > Remaining Estimate: 0h > > In order to aid developers and DevOps engineers who are working in a > git-driven ecosystem, it would be helpful to see the status builds in the > README. This is a standard for many open source projects. I think one could > debate whether we should have a multi-line build badge visual in the README > because people need to know about the builds for various versions and > platforms in the case of Lucene/Solr because it is such a large and widely > used project, in a variety of environments. The badges not only celebrate > that fact, they support its persistence in the future with new developers who > look for such information instictively. > I would recommend the active build pipelines (currently 8.x and 9.x) for each > platform, Linux, Windows, MacOSX, and Solaris. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865205#comment-16865205 ] ASF subversion and git services commented on SOLR-13452: Commit 2086657ebbddbb60a7881440c5ce2c2016609dfd in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2086657 ] SOLR-13452: Clean up debug code. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865198#comment-16865198 ] ASF subversion and git services commented on SOLR-13452: Commit a132c37fdfcadee89e2d102cc6d41786c5bc289c in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a132c37 ] SOLR-13452: Yet more work on dependencies and missingDependencies task. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7530) Wrong JSON response using Terms Component with distrib=true
[
https://issues.apache.org/jira/browse/SOLR-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865192#comment-16865192
]
Mikhail Khludnev commented on SOLR-7530:
Merged both patches. [~munendrasn], please have a look, especially at
CHANGES.txt, I'm worrying whether I've got right what's going on here. Thank
you.
> Wrong JSON response using Terms Component with distrib=true
> ---
>
> Key: SOLR-7530
> URL: https://issues.apache.org/jira/browse/SOLR-7530
> Project: Solr
> Issue Type: Bug
> Components: Response Writers, SearchComponents - other, SolrCloud
>Affects Versions: 4.9
>Reporter: Raúl Grande
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-7530.patch, SOLR-7530.patch, SOLR-7530.patch
>
>
> When using TermsComponent in SolrCloud there are differences in the JSON
> response if parameter distrib is true or false. If distrib=true JSON is not
> well formed (please note at the [ ] marks)
> JSON Response when distrib=false. Correct response:
> {"responseHeader":{
> "status":0,
> "QTime":3
> },
> "terms":{
> "FileType":
> [
> "EMAIL",20060,
> "PDF",7051,
> "IMAGE",5108,
> "OFFICE",4912,
> "TXT",4405,
> "OFFICE_EXCEL",4122,
> "OFFICE_WORD",2468
> ]
> } }
> JSON Response when distrib=true. Incorrect response:
> {
> "responseHeader":{
> "status":0,
> "QTime":94
> },
> "terms":{
> "FileType":{
> "EMAIL":31923,
> "PDF":11545,
> "IMAGE":9807,
> "OFFICE_EXCEL":8195,
> "OFFICE":5147,
> "OFFICE_WORD":4820,
> "TIFF":1156,
> "XML":851,
> "HTML":821,
> "RTF":303
> }
> } }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7530) Wrong JSON response using Terms Component with distrib=true
[
https://issues.apache.org/jira/browse/SOLR-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-7530:
---
Attachment: SOLR-7530.patch
> Wrong JSON response using Terms Component with distrib=true
> ---
>
> Key: SOLR-7530
> URL: https://issues.apache.org/jira/browse/SOLR-7530
> Project: Solr
> Issue Type: Bug
> Components: Response Writers, SearchComponents - other, SolrCloud
>Affects Versions: 4.9
>Reporter: Raúl Grande
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-7530.patch, SOLR-7530.patch, SOLR-7530.patch
>
>
> When using TermsComponent in SolrCloud there are differences in the JSON
> response if parameter distrib is true or false. If distrib=true JSON is not
> well formed (please note at the [ ] marks)
> JSON Response when distrib=false. Correct response:
> {"responseHeader":{
> "status":0,
> "QTime":3
> },
> "terms":{
> "FileType":
> [
> "EMAIL",20060,
> "PDF",7051,
> "IMAGE",5108,
> "OFFICE",4912,
> "TXT",4405,
> "OFFICE_EXCEL",4122,
> "OFFICE_WORD",2468
> ]
> } }
> JSON Response when distrib=true. Incorrect response:
> {
> "responseHeader":{
> "status":0,
> "QTime":94
> },
> "terms":{
> "FileType":{
> "EMAIL":31923,
> "PDF":11545,
> "IMAGE":9807,
> "OFFICE_EXCEL":8195,
> "OFFICE":5147,
> "OFFICE_WORD":4820,
> "TIFF":1156,
> "XML":851,
> "HTML":821,
> "RTF":303
> }
> } }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 24240 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24240/
Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops
-XX:+UseParallelGC
1 tests failed.
FAILED: junit.framework.TestSuite.org.apache.solr.core.DirectoryFactoryTest
Error Message:
The test or suite printed 1249127 bytes to stdout and stderr, even though the
limit was set to 8192 bytes. Increase the limit with @Limit, ignore it
completely with @SuppressSysoutChecks or run with -Dtests.verbose=true
Stack Trace:
java.lang.AssertionError: The test or suite printed 1249127 bytes to stdout and
stderr, even though the limit was set to 8192 bytes. Increase the limit with
@Limit, ignore it completely with @SuppressSysoutChecks or run with
-Dtests.verbose=true
at __randomizedtesting.SeedInfo.seed([DCD3712D5D435F4]:0)
at
org.apache.lucene.util.TestRuleLimitSysouts.afterIfSuccessful(TestRuleLimitSysouts.java:282)
at
com.carrotsearch.randomizedtesting.rules.TestRuleAdapter$1.afterIfSuccessful(TestRuleAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:37)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:830)
Build Log:
[...truncated 13869 lines...]
[junit4] Suite: org.apache.solr.core.DirectoryFactoryTest
[junit4] 2> 1308731 INFO (READER15) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={q=id:17=true=json}
hits=1 status=0 QTime=0
[junit4] 2> 1308731 INFO (READER5) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=0=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER3) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=16=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER15) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=3=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER5) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=9=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER5) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=11=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER15) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={q=id:8=true=json}
hits=0 status=0 QTime=0
[junit4] 2> 1308731 INFO (READER3) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=10=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER5) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={q=id:21=true=json}
hits=1 status=0 QTime=0
[junit4] 2> 1308731 INFO (READER15) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=15=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER3) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={q=id:5=true=json}
hits=1 status=0 QTime=0
[junit4] 2> 1308731 INFO (READER5) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=16=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER15) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=11=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER3) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=11=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER5) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={q=id:11=true=json}
hits=1 status=0 QTime=0
[junit4] 2> 1308731 INFO (READER15) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=6=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER3) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={q=id:0=true=json}
hits=1 status=0 QTime=0
[junit4] 2> 1308731 INFO (READER5) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=11=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER15) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=11=json} status=0
QTime=0
[junit4] 2> 1308731 INFO (READER3) [ ] o.a.s.c.S.Request
[collection1] webapp=null path=null params={qt=/get=5=json} status=0
QTime=0
[junit4] 2> 1308731 INFO
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865183#comment-16865183 ] ASF subversion and git services commented on SOLR-13452: Commit 81a4ef1262a0f03dda2e190634dee2e0670106f1 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=81a4ef1 ] SOLR-13452: More work on dependencies and missingDependencies task. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13190) Fuzzy search treated as server error instead of client error when terms are too complex
[
https://issues.apache.org/jira/browse/SOLR-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865172#comment-16865172
]
Mike Drob commented on SOLR-13190:
--
Looks like I failed to mention in this initial reporting that the query causing
these issues for us was a mixed Japanese and English term. Based on
conversations and additional digging, I suspect that our algorithm
fundamentally doesn't work on multi-code point characters. when converting to
utf8, I suspect that the transitions are tearing the characters apart and might
be producing nonsense suggestions for deleting or adding "half" a character. I
don't have proof of this though, so I'll have to assume that the algorithm
works.
That aside, the number of states scales linearly with length by a factor of 45,
as can be confirmed in Lev2TParametricDescription. For English (or any single
byte character text, I expect), that number of states does not change in the
32->8 conversion. But for JP text, we get approximately 256 states per
character post-conversion, starting with the 3rd character, and slightly
varying with the exact text itself. I start to see the TooComplexToDeterminize
come back with random strings of length 41 or 42.
Since we know that these aren't adversarial regular expressions, then I think
we should be safe to pass in a dynamically determined maximum number of states.
For pure utf8 text, I don't think it becomes undetermined, so the bound doesn't
matter. For other cases, length*256+100 for maybe a little bit of buffer might
be good enough.
> Fuzzy search treated as server error instead of client error when terms are
> too complex
> ---
>
> Key: SOLR-13190
> URL: https://issues.apache.org/jira/browse/SOLR-13190
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We've seen a fuzzy search end up breaking the automaton and getting reported
> as a server error. This usage should be improved by
> 1) reporting as a client error, because it's similar to something like too
> many boolean clauses queries in how an operator should deal with it
> 2) report what field is causing the error, since that currently must be
> deduced from adjacent query logs and can be difficult if there are multiple
> terms in the search
> This trigger was added to defend against adversarial regex but somehow hits
> fuzzy terms as well, I don't understand enough about the automaton mechanisms
> to really know how to approach a fix there, but improving the operability is
> a good first step.
> relevant stack trace:
> {noformat}
> org.apache.lucene.util.automaton.TooComplexToDeterminizeException:
> Determinizing automaton with 13632 states and 21348 transitions would result
> in more than 1 states.
> at
> org.apache.lucene.util.automaton.Operations.determinize(Operations.java:746)
> at
> org.apache.lucene.util.automaton.RunAutomaton.(RunAutomaton.java:69)
> at
> org.apache.lucene.util.automaton.ByteRunAutomaton.(ByteRunAutomaton.java:32)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:247)
> at
> org.apache.lucene.util.automaton.CompiledAutomaton.(CompiledAutomaton.java:133)
> at
> org.apache.lucene.search.FuzzyTermsEnum.(FuzzyTermsEnum.java:143)
> at org.apache.lucene.search.FuzzyQuery.getTermsEnum(FuzzyQuery.java:154)
> at
> org.apache.lucene.search.MultiTermQuery$RewriteMethod.getTermsEnum(MultiTermQuery.java:78)
> at
> org.apache.lucene.search.TermCollectingRewrite.collectTerms(TermCollectingRewrite.java:58)
> at
> org.apache.lucene.search.TopTermsRewrite.rewrite(TopTermsRewrite.java:67)
> at
> org.apache.lucene.search.MultiTermQuery.rewrite(MultiTermQuery.java:310)
> at
> org.apache.lucene.search.IndexSearcher.rewrite(IndexSearcher.java:667)
> at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:442)
> at
> org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:200)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1604)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1420)
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:567)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1435)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:374)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:298)
>
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #633: LUCENE-8753 UniformSplit PostingsFormat
dsmiley commented on a change in pull request #633: LUCENE-8753 UniformSplit
PostingsFormat
URL: https://github.com/apache/lucene-solr/pull/633#discussion_r294099629
##
File path:
lucene/test-framework/src/java/org/apache/lucene/codecs/uniformsplit/UniformSplitTestingCodec.java
##
@@ -0,0 +1,41 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.lucene.codecs.uniformsplit;
+
+import org.apache.lucene.codecs.PostingsFormat;
+import org.apache.lucene.codecs.lucene50.Lucene50StoredFieldsFormat;
+import org.apache.lucene.codecs.lucene80.Lucene80Codec;
+
+/**
+ * Codec that chooses {@link UniformSplitPostingsFormat}. The problem with
doing
+ * -Dtests.postingsformat=UniformSplitTesting instead is that it's awkward to
disable this on some Lucene tests.
Review comment:
I think we don't need this testing codec? I read your javadoc comments here
but there is no case yet where we want to disable uniformsplit (or any other
particular PostingsFormat for that matter).
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8848) UnifiedHighlighter should highlight all Query types that implement Weight.matches
[ https://issues.apache.org/jira/browse/LUCENE-8848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865141#comment-16865141 ] David Smiley commented on LUCENE-8848: -- I'll commit this Wednesday on the 19th, the day after Berlin Buzzwords is over in case you or others need more time to review. > UnifiedHighlighter should highlight all Query types that implement > Weight.matches > - > > Key: LUCENE-8848 > URL: https://issues.apache.org/jira/browse/LUCENE-8848 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/highlighter >Reporter: David Smiley >Priority: Major > Attachments: LUCENE-8848.patch > > > The UnifiedHighlighter internally extracts terms and automata from the query. > Usually this works perfectly but it's possible a Query might be of a type it > doesn't know -- a leaf query that is perhaps in effect similar to a > MultiTermQuery yet it might not even be a subclass of this or it does but the > UH doesn't know how to extract an automata from it. The UH is oblivious to > this and probably won't highlight this query. If re-analysis of the text is > necessary, the UH will pre-filter all terms to only those it _thinks_ are > pertinent. Or if offsets are in the postings then the UH could perform very > poorly by unleashing this query on the index for each highlighted document > without recognizing re-analysis is a more appropriate path. > I think to solve this, the UnifiedHighlighter.getFieldHighlighter needs to > inspect the query (using a QueryVisitor) to see if it can find a leaf query > that is not one it knows how to pull automata from, and is otherwise not in a > special list (like MatchAllDocsQuery). If we find one, we avoid choosing > OffsetSource.POSTINGS or OffsetSource.NONE_NEEDED since we might in effect > have an MTQ like query. If a MemoryIndex is needed then we don't pre-filter > the terms since we can't assume we know precisely which terms are pertinent. > We needn't bother extracting terms & automata in this case either; it's > wasted effort which can involve building a CharacterRunAutomaton (see > MultiTermHighlighting.binaryToCharRunAutomaton). Speaking of which, it'd be > nice to avoid that in other cases as well, like for WEIGHT_MATCHES when we > aren't using MemoryIndex (thus no term pre-filtering). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Windows (64bit/jdk-10.0.1) - Build # 313 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Windows/313/ Java: 64bit/jdk-10.0.1 -XX:+UseCompressedOops -XX:+UseParallelGC 3 tests failed. FAILED: org.apache.solr.cloud.OverseerTest.testShardLeaderChange Error Message: Captured an uncaught exception in thread: Thread[id=330, name=OverseerCollectionConfigSetProcessor-72079276911755287-127.0.0.1:65339_solr-n_00, state=RUNNABLE, group=Overseer collection creation process.] Stack Trace: com.carrotsearch.randomizedtesting.UncaughtExceptionError: Captured an uncaught exception in thread: Thread[id=330, name=OverseerCollectionConfigSetProcessor-72079276911755287-127.0.0.1:65339_solr-n_00, state=RUNNABLE, group=Overseer collection creation process.] at __randomizedtesting.SeedInfo.seed([3223CDF0C003C3F0:EC704A07DA9B3601]:0) Caused by: org.apache.solr.common.AlreadyClosedException at __randomizedtesting.SeedInfo.seed([3223CDF0C003C3F0]:0) at org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:69) at org.apache.solr.common.cloud.SolrZkClient.getData(SolrZkClient.java:337) at org.apache.solr.cloud.OverseerTaskProcessor.amILeader(OverseerTaskProcessor.java:425) at org.apache.solr.cloud.OverseerTaskProcessor.run(OverseerTaskProcessor.java:156) at java.base/java.lang.Thread.run(Thread.java:844) FAILED: org.apache.solr.cloud.OverseerTest.testOverseerFailure Error Message: Test abandoned because suite timeout was reached. Stack Trace: java.lang.Exception: Test abandoned because suite timeout was reached. at __randomizedtesting.SeedInfo.seed([3223CDF0C003C3F0]:0) FAILED: junit.framework.TestSuite.org.apache.solr.cloud.OverseerTest Error Message: Suite timeout exceeded (>= 720 msec). Stack Trace: java.lang.Exception: Suite timeout exceeded (>= 720 msec). at __randomizedtesting.SeedInfo.seed([3223CDF0C003C3F0]:0) Build Log: [...truncated 15733 lines...] [junit4] Suite: org.apache.solr.cloud.OverseerTest [junit4] 2> Creating dataDir: C:\Users\jenkins\workspace\Lucene-Solr-8.x-Windows\solr\build\solr-core\test\J0\temp\solr.cloud.OverseerTest_3223CDF0C003C3F0-001\init-core-data-001 [junit4] 2> 495902 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.SolrTestCaseJ4 Using PointFields (NUMERIC_POINTS_SYSPROP=true) w/NUMERIC_DOCVALUES_SYSPROP=false [junit4] 2> 495904 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.SolrTestCaseJ4 Randomized ssl (false) and clientAuth (false) via: @org.apache.solr.util.RandomizeSSL(reason="", value=0.0/0.0, ssl=0.0/0.0, clientAuth=0.0/0.0) [junit4] 2> 495904 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.SolrTestCaseJ4 SecureRandom sanity checks: test.solr.allowed.securerandom=null & java.security.egd=file:/dev/./urandom [junit4] 2> 495935 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.c.ZkTestServer STARTING ZK TEST SERVER [junit4] 2> 495936 INFO (ZkTestServer Run Thread) [ ] o.a.s.c.ZkTestServer client port:0.0.0.0/0.0.0.0:0 [junit4] 2> 495936 INFO (ZkTestServer Run Thread) [ ] o.a.s.c.ZkTestServer Starting server [junit4] 2> 496036 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.c.ZkTestServer start zk server on port:60995 [junit4] 2> 496036 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.c.ZkTestServer parse host and port list: 127.0.0.1:60995 [junit4] 2> 496036 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.c.ZkTestServer connecting to 127.0.0.1 60995 [junit4] 2> 496039 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 496065 INFO (zkConnectionManagerCallback-2082-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 496065 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 496067 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.c.c.ConnectionManager Waiting for client to connect to ZooKeeper [junit4] 2> 496081 INFO (zkConnectionManagerCallback-2084-thread-1) [ ] o.a.s.c.c.ConnectionManager zkClient has connected [junit4] 2> 496082 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.c.c.ConnectionManager Client is connected to ZooKeeper [junit4] 2> 496082 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.SolrTestCaseJ4 initCore [junit4] 2> 496082 INFO (SUITE-OverseerTest-seed#[3223CDF0C003C3F0]-worker) [ ] o.a.s.SolrTestCaseJ4 initCore end [junit4] 2> 496094 INFO (TEST-OverseerTest.testStateChange-seed#[3223CDF0C003C3F0]) [ ] o.a.s.SolrTestCaseJ4 ###Starting testStateChange
[jira] [Closed] (SOLR-6096) Support Update and Delete on nested documents
[
https://issues.apache.org/jira/browse/SOLR-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley closed SOLR-6096.
--
> Support Update and Delete on nested documents
> -
>
> Key: SOLR-6096
> URL: https://issues.apache.org/jira/browse/SOLR-6096
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.7.2
>Reporter: Thomas Scheffler
>Priority: Major
> Labels: blockjoin, nested
> Fix For: 8.0
>
>
> When using nested or child document. Update and delete operation on the root
> document should also affect the nested documents, as no child can exist
> without its parent :-)
> Example
> {code:xml|title=First Import}
>
> 1
> Article with author
>
> Smith, John
> author
>
>
> {code}
> If I change my mind and the author was not named *John* but *_Jane_*:
> {code:xml|title=Changed name of author of '1'}
>
> 1
> Article with author
>
> Smith, Jane
> author
>
>
> {code}
> I would expect that John is not in the index anymore. Currently he is. There
> might also be the case that any subdocument is removed by an update:
> {code:xml|title=Remove author}
>
> 1
> Article without author
>
> {code}
> This should affect a delete on all nested documents, too. The same way all
> nested documents should be deleted if I delete the root document:
> {code:xml|title=Deletion of '1'}
>
> 1
>
>
> {code}
> This is currently possible to do all this stuff on client side by issuing
> additional request to delete document before every update. It would be more
> efficient if this could be handled on SOLR side. One would benefit on atomic
> update. The biggest plus shows when using "delete-by-query".
> {code:xml|title=Deletion of '1' by query}
>
> title:*
>
>
> {code}
> In that case one would not have to first query all documents and issue
> deletes by those id and every document that are nested.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-6096) Support Update and Delete on nested documents
[
https://issues.apache.org/jira/browse/SOLR-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-6096.
Resolution: Duplicate
Fix Version/s: 8.0
I'm closing this as a Duplicate, of multiple issues that basically fixed this
for 8.0. Not everything is perfect... in particular one has to be careful with
delete-by-query but that's at least documented now. That will be difficult to
address.
> Support Update and Delete on nested documents
> -
>
> Key: SOLR-6096
> URL: https://issues.apache.org/jira/browse/SOLR-6096
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.7.2
>Reporter: Thomas Scheffler
>Priority: Major
> Labels: blockjoin, nested
> Fix For: 8.0
>
>
> When using nested or child document. Update and delete operation on the root
> document should also affect the nested documents, as no child can exist
> without its parent :-)
> Example
> {code:xml|title=First Import}
>
> 1
> Article with author
>
> Smith, John
> author
>
>
> {code}
> If I change my mind and the author was not named *John* but *_Jane_*:
> {code:xml|title=Changed name of author of '1'}
>
> 1
> Article with author
>
> Smith, Jane
> author
>
>
> {code}
> I would expect that John is not in the index anymore. Currently he is. There
> might also be the case that any subdocument is removed by an update:
> {code:xml|title=Remove author}
>
> 1
> Article without author
>
> {code}
> This should affect a delete on all nested documents, too. The same way all
> nested documents should be deleted if I delete the root document:
> {code:xml|title=Deletion of '1'}
>
> 1
>
>
> {code}
> This is currently possible to do all this stuff on client side by issuing
> additional request to delete document before every update. It would be more
> efficient if this could be handled on SOLR side. One would benefit on atomic
> update. The biggest plus shows when using "delete-by-query".
> {code:xml|title=Deletion of '1' by query}
>
> title:*
>
>
> {code}
> In that case one would not have to first query all documents and issue
> deletes by those id and every document that are nested.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7530) Wrong JSON response using Terms Component with distrib=true
[
https://issues.apache.org/jira/browse/SOLR-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865132#comment-16865132
]
Lucene/Solr QA commented on SOLR-7530:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
43s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Release audit (RAT) {color} |
{color:green} 3m 7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Check forbidden APIs {color} |
{color:green} 3m 7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} Validate source patterns {color} |
{color:green} 3m 8s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 91m 8s{color}
| {color:red} core in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}103m 23s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | solr.handler.component.DistributedTermsComponentTest |
| | solr.cloud.AliasIntegrationTest |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-7530 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12971907/SOLR-7530.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene2-us-west.apache.org 4.4.0-112-generic #135-Ubuntu SMP
Fri Jan 19 11:48:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-SOLR-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / ded3b77 |
| ant | version: Apache Ant(TM) version 1.9.6 compiled on July 20 2018 |
| Default Java | LTS |
| unit |
https://builds.apache.org/job/PreCommit-SOLR-Build/438/artifact/out/patch-unit-solr_core.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-SOLR-Build/438/testReport/ |
| modules | C: solr/core U: solr/core |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/438/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Wrong JSON response using Terms Component with distrib=true
> ---
>
> Key: SOLR-7530
> URL: https://issues.apache.org/jira/browse/SOLR-7530
> Project: Solr
> Issue Type: Bug
> Components: Response Writers, SearchComponents - other, SolrCloud
>Affects Versions: 4.9
>Reporter: Raúl Grande
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-7530.patch, SOLR-7530.patch
>
>
> When using TermsComponent in SolrCloud there are differences in the JSON
> response if parameter distrib is true or false. If distrib=true JSON is not
> well formed (please note at the [ ] marks)
> JSON Response when distrib=false. Correct response:
> {"responseHeader":{
> "status":0,
> "QTime":3
> },
> "terms":{
> "FileType":
> [
> "EMAIL",20060,
> "PDF",7051,
> "IMAGE",5108,
> "OFFICE",4912,
> "TXT",4405,
> "OFFICE_EXCEL",4122,
> "OFFICE_WORD",2468
> ]
> } }
> JSON Response when distrib=true. Incorrect response:
> {
> "responseHeader":{
> "status":0,
> "QTime":94
> },
> "terms":{
> "FileType":{
> "EMAIL":31923,
> "PDF":11545,
> "IMAGE":9807,
> "OFFICE_EXCEL":8195,
> "OFFICE":5147,
> "OFFICE_WORD":4820,
> "TIFF":1156,
> "XML":851,
> "HTML":821,
> "RTF":303
> }
> } }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SOLR-13437) fork noggit code to Solr
[ https://issues.apache.org/jira/browse/SOLR-13437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865117#comment-16865117 ] David Smiley commented on SOLR-13437: - Spatial4j uses Noggit for GeoJSON parsing. It's considered an "optional" dependency, and thus if Noggit isn't on the classpath then the GeoJSON parsing feature isn't enabled. Spatial4j can still _write_ GeoJSON which doesn't use any libs. https://github.com/locationtech/spatial4j/blob/master/src/main/java/org/locationtech/spatial4j/io/GeoJSONReader.java One way to handle this is to fork that one class into Solr and simply change the import statement. There's more to it though... need to register this shape reader in org.apache.solr.schema.AbstractSpatialFieldType#init > fork noggit code to Solr > > > Key: SOLR-13437 > URL: https://issues.apache.org/jira/browse/SOLR-13437 > Project: Solr > Issue Type: Task > Components: SolrJ >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > We rely on noggit for all our JSON encoding/decoding needs.The main project > is not actively maintained . We cannot easily switch to another parser > because it may cause backward incompatibility and we have advertised the > ability to use flexible JSON and we also use noggit internally in many classes -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865111#comment-16865111
]
ASF subversion and git services commented on SOLR-13105:
Commit 69280914a3de60b01e3495ce2e63965dfd73c360 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6928091 ]
SOLR-13105: Add initial search docs
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-8.x - Build # 239 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-8.x/239/ 2 tests failed. FAILED: org.apache.solr.cloud.RollingRestartTest.test Error Message: No overseer designate as leader found after restart #1: 127.0.0.1:39995_ Stack Trace: java.lang.AssertionError: No overseer designate as leader found after restart #1: 127.0.0.1:39995_ at __randomizedtesting.SeedInfo.seed([E24F286AF8ADBCBE:6A1B17B05651D146]:0) at org.junit.Assert.fail(Assert.java:88) at org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:101) at org.apache.solr.cloud.RollingRestartTest.test(RollingRestartTest.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at
[JENKINS-EA] Lucene-Solr-master-Linux (64bit/jdk-13-ea+shipilev-fastdebug) - Build # 24239 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24239/ Java: 64bit/jdk-13-ea+shipilev-fastdebug -XX:+UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 7701 lines...] [junit4] JVM J2: stdout was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/facet/test/temp/junit4-J2-20190616_174217_89415100748691654584036.sysout [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] # To suppress the following error report, specify this argument [junit4] # after -XX: or in .hotspotrc: SuppressErrorAt=/loopPredicate.cpp:315 [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # Internal Error (/home/buildbot/worker/jdkX-linux/build/src/hotspot/share/opto/loopPredicate.cpp:315), pid=14861, tid=14988 [junit4] # assert(dom_r->unique_ctrl_out()->is_Call()) failed: unc expected [junit4] # [junit4] # JRE version: OpenJDK Runtime Environment (13.0) (fastdebug build 13-testing+0-builds.shipilev.net-openjdk-jdk-b845-20190430-jdk-1318) [junit4] # Java VM: OpenJDK 64-Bit Server VM (fastdebug 13-testing+0-builds.shipilev.net-openjdk-jdk-b845-20190430-jdk-1318, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64) [junit4] # Problematic frame: [junit4] # V [libjvm.so+0x111d07d] PhaseIdealLoop::clone_loop_predicates_fix_mem(ProjNode*, ProjNode*, PhaseIdealLoop*, PhaseIterGVN*)+0x12d [junit4] # [junit4] # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again [junit4] # [junit4] # An error report file with more information is saved as: [junit4] # /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/facet/test/J2/hs_err_pid14861.log [junit4] # [junit4] # Compiler replay data is saved as: [junit4] # /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/facet/test/J2/replay_pid14861.log [junit4] # [junit4] # If you would like to submit a bug report, please visit: [junit4] # http://bugreport.java.com/bugreport/crash.jsp [junit4] # [junit4] Current thread is 14988 [junit4] Dumping core ... [junit4] <<< JVM J2: EOF [junit4] JVM J2: stderr was not empty, see: /home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/facet/test/temp/junit4-J2-20190616_174217_89412678981596062686542.syserr [junit4] >>> JVM J2 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: increase O_BUFLEN in ostream.hpp -- output truncated [junit4] <<< JVM J2: EOF [...truncated 33 lines...] [junit4] ERROR: JVM J2 ended with an exception, command line: /home/jenkins/tools/java/64bit/jdk-13-ea+shipilev-fastdebug/bin/java -XX:+UseCompressedOops -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/jenkins/workspace/Lucene-Solr-master-Linux/heapdumps -ea -esa --illegal-access=deny -Dtests.prefix=tests -Dtests.seed=8B96B21E6EDB5C67 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=9.0.0 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.monster=false -Dtests.slow=true -Dtests.asserts=true -Dtests.multiplier=3 -DtempDir=./temp -Djava.io.tmpdir=./temp -Dcommon.dir=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene -Dclover.db.dir=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/clover/db -Djava.security.policy=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/tools/junit4/tests.policy -Dtests.LUCENE_VERSION=9.0.0 -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 -Dtests.src.home=/home/jenkins/workspace/Lucene-Solr-master-Linux -Djava.security.egd=file:/dev/./urandom -Djunit4.childvm.cwd=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/facet/test/J2 -Djunit4.tempDir=/home/jenkins/workspace/Lucene-Solr-master-Linux/lucene/build/facet/test/temp -Djunit4.childvm.id=2 -Djunit4.childvm.count=3 -Dfile.encoding=ISO-8859-1 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Dtests.filterstacks=true -Dtests.leaveTemporary=false -Dtests.badapples=false -classpath
[jira] [Comment Edited] (SOLR-13434) OpenTracing support for Solr
[
https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865090#comment-16865090
]
Ishan Chattopadhyaya edited comment on SOLR-13434 at 6/16/19 5:28 PM:
--
# The cluster property {{samplePercentage}} seems a bit too generic, since
there are so many other places where we might want to use sampling. How about
we change it to {{tracingSamplePercentage}}?
# Is there a way to specify a pattern for excluding certain types of requests /
log items from being traced? Specifically, I was looking to stop the
healthcheck requests from being sent for tracing.
was (Author: ichattopadhyaya):
# The cluster property {{samplePercentage}} seems a bit too generic, since
there are so many other places where we might want to use sampling. How about
we change it to {{tracingSamplePercentage}}?
# Is there a way to specify a pattern for excluding certain types of log items
from being traced? Specifically, I was looking to stop the healthcheck logs
from being sent for tracing.
> OpenTracing support for Solr
>
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
> Issue Type: New Feature
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger,
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing
> APIs. Ideally, we can implement it once and have integrations for popular
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack
> of activity so this is a fresh attempt at solving this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[
https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865090#comment-16865090
]
Ishan Chattopadhyaya commented on SOLR-13434:
-
# The cluster property {{samplePercentage}} seems a bit too generic, since
there are so many other places where we might want to use sampling. How about
we change it to {{tracingSamplePercentage}}?
# Is there a way to specify a pattern for excluding certain types of log items
from being traced? Specifically, I was looking to stop the healthcheck logs
from being sent for tracing.
> OpenTracing support for Solr
>
>
> Key: SOLR-13434
> URL: https://issues.apache.org/jira/browse/SOLR-13434
> Project: Solr
> Issue Type: New Feature
>Reporter: Shalin Shekhar Mangar
>Assignee: Cao Manh Dat
>Priority: Major
> Fix For: master (9.0), 8.2
>
> Attachments: SOLR-13434.patch
>
> Time Spent: 7h 40m
> Remaining Estimate: 0h
>
> [OpenTracing|https://opentracing.io/] is a vendor neutral API and
> infrastructure for distributed tracing. Many OSS tracers just as Jaeger,
> OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing
> APIs. Ideally, we can implement it once and have integrations for popular
> tracers like we have with metrics and prometheus.
> I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack
> of activity so this is a fresh attempt at solving this problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865088#comment-16865088 ] ASF subversion and git services commented on SOLR-13434: Commit 4c11ef336788efefe25c60130c150089e28acd21 in lucene-solr's branch refs/heads/branch_8x from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4c11ef3 ] SOLR-13434: Fixing documentation regarding samplePercentage clusterprop > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865087#comment-16865087 ] ASF subversion and git services commented on SOLR-13434: Commit ded3b77171add20bd14ae817135cf31597d09446 in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ded3b77 ] SOLR-13434: Fixing documentation regarding samplePercentage clusterprop > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-8.x #128: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-8.x/128/ No tests ran. Build Log: [...truncated 33497 lines...] [mvn] [INFO] - [mvn] [INFO] - [mvn] [ERROR] COMPILATION ERROR : [mvn] [INFO] - [...truncated 877 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-8.x/build.xml:680: The following error occurred while executing this line: : Java returned: 1 Total time: 18 minutes 38 seconds Build step 'Invoke Ant' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-master - Build # 1364 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-master/1364/ No tests ran. Build Log: [...truncated 24664 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2580 links (2111 relative) to 3392 anchors in 259 files [echo] Validated Links & Anchors via: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked [untar] Expanding: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/package/solr-9.0.0.tgz into /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-master/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail:
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-11.0.2) - Build # 7999 - Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7999/ Java: 64bit/jdk-11.0.2 -XX:-UseCompressedOops -XX:+UseSerialGC 1 tests failed. FAILED: org.apache.solr.cloud.OverseerRolesTest.testOverseerRole Error Message: Timed out waiting for overseer state change. The current overseer is: 127.0.0.1:63377_solr Stack Trace: java.lang.AssertionError: Timed out waiting for overseer state change. The current overseer is: 127.0.0.1:63377_solr at __randomizedtesting.SeedInfo.seed([2B84DC46FD0E62F8:CA4F21D2C6BD5429]:0) at org.junit.Assert.fail(Assert.java:88) at org.apache.solr.cloud.OverseerRolesTest.waitForNewOverseer(OverseerRolesTest.java:75) at org.apache.solr.cloud.OverseerRolesTest.testOverseerRole(OverseerRolesTest.java:162) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) Build Log: [...truncated 13125 lines...] [junit4] Suite: org.apache.solr.cloud.OverseerRolesTest [junit4] 2> 607167 INFO
[jira] [Commented] (SOLR-13434) OpenTracing support for Solr
[ https://issues.apache.org/jira/browse/SOLR-13434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865061#comment-16865061 ] Daniel Collins commented on SOLR-13434: --- [https://github.com/apache/lucene-solr/pull/720] might help, I entered that for SOLR-13549, which was specifically about the Solr tests not building due to a dependency on opentracking-mock. Currently my branch_8x isn't building with Maven due to forbiddenapi issues, but I'll try again later > OpenTracing support for Solr > > > Key: SOLR-13434 > URL: https://issues.apache.org/jira/browse/SOLR-13434 > Project: Solr > Issue Type: New Feature >Reporter: Shalin Shekhar Mangar >Assignee: Cao Manh Dat >Priority: Major > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13434.patch > > Time Spent: 7h 40m > Remaining Estimate: 0h > > [OpenTracing|https://opentracing.io/] is a vendor neutral API and > infrastructure for distributed tracing. Many OSS tracers just as Jaeger, > OpenZipkin, Apache SkyWalking as well as commercial tools support OpenTracing > APIs. Ideally, we can implement it once and have integrations for popular > tracers like we have with metrics and prometheus. > I'm aware of SOLR-9641 but HTrace has since retired from incubator for lack > of activity so this is a fresh attempt at solving this problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13347) Error writing Transaction log for UUIDField
[ https://issues.apache.org/jira/browse/SOLR-13347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865062#comment-16865062 ] David Smiley commented on SOLR-13347: - "we never claimed to support UUID" Where are the claims of what we support? I never new atomic updates was limited to only specific field types; I suspect our users never new either. If we are only to support a predetermined list of fields, then this sounds like an enhancement then. [~hossman] once expressed concern that we overuse "other" category when we ought to _try_ to better categorize as something else. I think we can do that here. > Error writing Transaction log for UUIDField > --- > > Key: SOLR-13347 > URL: https://issues.apache.org/jira/browse/SOLR-13347 > Project: Solr > Issue Type: Bug > Components: Server >Affects Versions: 7.7, 7.7.1, 8.0 >Reporter: Thomas Wöckinger >Assignee: Noble Paul >Priority: Major > Labels: pull-request-available, ready-to-commit, test > Fix For: master (9.0), 8.2 > > Attachments: SOLR-13347.patch > > Time Spent: 4h > Remaining Estimate: 0h > > When using Atomic Update, adding a value leads to following Exception > org.apache.solr.common.SolrException: TransactionLog doesn't know how to > serialize class java.util.UUID; try implementing ObjectResolver? > at > org.apache.solr.update.TransactionLog$1.resolve(TransactionLog.java:100) > at > org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:263) > at > org.apache.solr.common.util.JavaBinCodec.writeArray(JavaBinCodec.java:770) > at > org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:369) > at > org.apache.solr.common.util.JavaBinCodec.writeKnownType(JavaBinCodec.java:362) > at > org.apache.solr.common.util.JavaBinCodec.writeVal(JavaBinCodec.java:252) > at > org.apache.solr.common.util.JavaBinCodec$BinEntryWriter.put(JavaBinCodec.java:437) > at > org.apache.solr.common.MapWriter$EntryWriter.putNoEx(MapWriter.java:100) > at > org.apache.solr.common.MapWriter$EntryWriter.lambda$getBiConsumer$0(MapWriter.java:160) > at java.base/java.util.LinkedHashMap.forEach(LinkedHashMap.java:684) > at > org.apache.solr.common.SolrInputDocument.writeMap(SolrInputDocument.java:51) > at > org.apache.solr.common.util.JavaBinCodec.writeSolrInputDocument(JavaBinCodec.java:657) > at org.apache.solr.update.TransactionLog.write(TransactionLog.java:371) > at org.apache.solr.update.UpdateLog.add(UpdateLog.java:573) > at org.apache.solr.update.UpdateLog.add(UpdateLog.java:552) > at > org.apache.solr.update.DirectUpdateHandler2.doNormalUpdate(DirectUpdateHandler2.java:351) > at > org.apache.solr.update.DirectUpdateHandler2.addDoc0(DirectUpdateHandler2.java:289) > at > org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:236) > at > org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:76) > at > org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:55) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:995) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1216) > at > org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:700) > at > org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:103) > at > org.apache.solr.handler.loader.JavabinLoader$1.update(JavabinLoader.java:110) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:327) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readIterator(JavaBinUpdateRequestCodec.java:280) > at > org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:335) > at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$StreamingCodec.readNamedList(JavaBinUpdateRequestCodec.java:235) > at > org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:300) > at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280) > at > org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:193) > at > org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:126) > at > org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:123) > at
[GitHub] [lucene-solr] dsmiley commented on issue #721: LUCENE-8781: add FST array-with-gap addressing to Util.readCeilArc
dsmiley commented on issue #721: LUCENE-8781: add FST array-with-gap addressing to Util.readCeilArc URL: https://github.com/apache/lucene-solr/pull/721#issuecomment-502463878 Thanks. Did you try this out / test it? I recommend running the tests while changing the default FST to use array-with-gap addressing. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4 was: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] [ https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4| https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4] > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-13452: --- Description: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] [ https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4| https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4] was: I took some things from the great work that Dat did in [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a little further. When working with gradle in sub modules directly, I recommend [https://github.com/dougborg/gdub] This gradle branch uses the following plugin for version locking, version configuration and version consistency across modules: [https://github.com/palantir/gradle-consistent-versions] https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > [ https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4| > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_4] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-7530) Wrong JSON response using Terms Component with distrib=true
[
https://issues.apache.org/jira/browse/SOLR-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865047#comment-16865047
]
Mikhail Khludnev commented on SOLR-7530:
I'd like to propose more invasive testing approach. see attach
> Wrong JSON response using Terms Component with distrib=true
> ---
>
> Key: SOLR-7530
> URL: https://issues.apache.org/jira/browse/SOLR-7530
> Project: Solr
> Issue Type: Bug
> Components: Response Writers, SearchComponents - other, SolrCloud
>Affects Versions: 4.9
>Reporter: Raúl Grande
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-7530.patch, SOLR-7530.patch
>
>
> When using TermsComponent in SolrCloud there are differences in the JSON
> response if parameter distrib is true or false. If distrib=true JSON is not
> well formed (please note at the [ ] marks)
> JSON Response when distrib=false. Correct response:
> {"responseHeader":{
> "status":0,
> "QTime":3
> },
> "terms":{
> "FileType":
> [
> "EMAIL",20060,
> "PDF",7051,
> "IMAGE",5108,
> "OFFICE",4912,
> "TXT",4405,
> "OFFICE_EXCEL",4122,
> "OFFICE_WORD",2468
> ]
> } }
> JSON Response when distrib=true. Incorrect response:
> {
> "responseHeader":{
> "status":0,
> "QTime":94
> },
> "terms":{
> "FileType":{
> "EMAIL":31923,
> "PDF":11545,
> "IMAGE":9807,
> "OFFICE_EXCEL":8195,
> "OFFICE":5147,
> "OFFICE_WORD":4820,
> "TIFF":1156,
> "XML":851,
> "HTML":821,
> "RTF":303
> }
> } }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-7530) Wrong JSON response using Terms Component with distrib=true
[
https://issues.apache.org/jira/browse/SOLR-7530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Khludnev updated SOLR-7530:
---
Attachment: SOLR-7530.patch
> Wrong JSON response using Terms Component with distrib=true
> ---
>
> Key: SOLR-7530
> URL: https://issues.apache.org/jira/browse/SOLR-7530
> Project: Solr
> Issue Type: Bug
> Components: Response Writers, SearchComponents - other, SolrCloud
>Affects Versions: 4.9
>Reporter: Raúl Grande
>Assignee: Mikhail Khludnev
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-7530.patch, SOLR-7530.patch
>
>
> When using TermsComponent in SolrCloud there are differences in the JSON
> response if parameter distrib is true or false. If distrib=true JSON is not
> well formed (please note at the [ ] marks)
> JSON Response when distrib=false. Correct response:
> {"responseHeader":{
> "status":0,
> "QTime":3
> },
> "terms":{
> "FileType":
> [
> "EMAIL",20060,
> "PDF",7051,
> "IMAGE",5108,
> "OFFICE",4912,
> "TXT",4405,
> "OFFICE_EXCEL",4122,
> "OFFICE_WORD",2468
> ]
> } }
> JSON Response when distrib=true. Incorrect response:
> {
> "responseHeader":{
> "status":0,
> "QTime":94
> },
> "terms":{
> "FileType":{
> "EMAIL":31923,
> "PDF":11545,
> "IMAGE":9807,
> "OFFICE_EXCEL":8195,
> "OFFICE":5147,
> "OFFICE_WORD":4820,
> "TIFF":1156,
> "XML":851,
> "HTML":821,
> "RTF":303
> }
> } }
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865044#comment-16865044 ] ASF subversion and git services commented on SOLR-13452: Commit e96ed6d7f52a4e674e7ab7e3e69a8ea4ebf167ed in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_4 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e96ed6d ] SOLR-13452: More work on dependencies and related tasks. > Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle. > - > > Key: SOLR-13452 > URL: https://issues.apache.org/jira/browse/SOLR-13452 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Mark Miller >Assignee: Mark Miller >Priority: Major > Fix For: master (9.0) > > > I took some things from the great work that Dat did in > [https://github.com/apache/lucene-solr/tree/jira/gradle] and took the ball a > little further. > > When working with gradle in sub modules directly, I recommend > [https://github.com/dougborg/gdub] > This gradle branch uses the following plugin for version locking, version > configuration and version consistency across modules: > [https://github.com/palantir/gradle-consistent-versions] > > https://github.com/apache/lucene-solr/tree/jira/SOLR-13452_gradle_3 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #724: SOLR-13523: Atomic Update results in NullPointerException
dsmiley commented on a change in pull request #724: SOLR-13523: Atomic Update results in NullPointerException URL: https://github.com/apache/lucene-solr/pull/724#discussion_r294084842 ## File path: solr/core/src/test-files/solr/collection1/conf/schema.xml ## @@ -608,7 +609,7 @@ - + Review comment: remove this; I had done this only to troubleshoot This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #724: SOLR-13523: Atomic Update results in NullPointerException
dsmiley commented on a change in pull request #724: SOLR-13523: Atomic Update
results in NullPointerException
URL: https://github.com/apache/lucene-solr/pull/724#discussion_r294084826
##
File path: solr/core/src/java/org/apache/solr/schema/IndexSchema.java
##
@@ -1970,6 +1970,14 @@ public boolean savesChildDocRelations() {
if (!isUsableForChildDocs()) {
return false;
}
+
+// can not be null, since IndexSchema#isUsableForChildDocs returned true
+FieldType rootType = getFieldTypeNoEx(ROOT_FIELD_NAME);
+if (!rootType.hasProperty(FieldProperties.STORED)) {
Review comment:
I don't think we should add this constraint; the nest path field is plenty
useful with root stored=false. It enables the child doc transformer to return
a nested structure. It enables queries to use the index of the nest path to
constraint results. And *some* atomic updates are possible that involve nested
documents -- so long as the top/parent document provided is a root document.
Such an atomic update might add or update children.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #724: SOLR-13523: Atomic Update results in NullPointerException
dsmiley commented on a change in pull request #724: SOLR-13523: Atomic Update results in NullPointerException URL: https://github.com/apache/lucene-solr/pull/724#discussion_r294084854 ## File path: solr/core/src/test-files/solr/collection1/conf/solrconfig.xml ## @@ -30,6 +30,65 @@ + Review comment: Again; remove this. I had added this only to troubleshoot to see if schemaless is related. It isn't. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #724: SOLR-13523: Atomic Update results in NullPointerException
dsmiley commented on a change in pull request #724: SOLR-13523: Atomic Update
results in NullPointerException
URL: https://github.com/apache/lucene-solr/pull/724#discussion_r294084897
##
File path:
solr/solrj/src/test/org/apache/solr/client/solrj/SolrExampleTests.java
##
@@ -1789,30 +1789,41 @@ public void testUpdateMultiValuedField() throws
Exception {
SolrClient solrClient = getSolrClient();
SolrInputDocument doc = new SolrInputDocument();
doc.addField("id", "123");
+doc.addField("cat", "first");//creates the field by side-effect
Review comment:
I think we don't have to modify this method to show the problem after all.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-master #2587: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-master/2587/ No tests ran. Build Log: [...truncated 35058 lines...] BUILD FAILED /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-Maven-master/build.xml:680: The following error occurred while executing this line: : Java returned: 1 Total time: 21 minutes 52 seconds Build step 'Invoke Ant' marked build as failure Email was triggered for: Failure - Any Sending email for trigger: Failure - Any - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-repro-Java11 - Build # 148 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro-Java11/148/ [...truncated 28 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1872/consoleText [repro] Revision: 412496a9944ec913ff0f43f84f72d73b274704f1 [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=RollingRestartTest -Dtests.method=test -Dtests.seed=62F92A55875C823E -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=en-BB -Dtests.timezone=Africa/Brazzaville -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] Repro line: ant test -Dtestcase=HdfsAutoAddReplicasIntegrationTest -Dtests.method=testSimple -Dtests.seed=62F92A55875C823E -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=en-TK -Dtests.timezone=America/Miquelon -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 412496a9944ec913ff0f43f84f72d73b274704f1 [repro] git fetch [repro] git checkout 412496a9944ec913ff0f43f84f72d73b274704f1 [...truncated 1 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] HdfsAutoAddReplicasIntegrationTest [repro] RollingRestartTest [repro] ant compile-test [...truncated 3311 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=10 -Dtests.class="*.HdfsAutoAddReplicasIntegrationTest|*.RollingRestartTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.seed=62F92A55875C823E -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-master/test-data/enwiki.random.lines.txt -Dtests.locale=en-TK -Dtests.timezone=America/Miquelon -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [...truncated 7982 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 0/5 failed: org.apache.solr.cloud.RollingRestartTest [repro] 3/5 failed: org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest [repro] git checkout 412496a9944ec913ff0f43f84f72d73b274704f1 [...truncated 1 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 122 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/122/ No tests ran. Build Log: [...truncated 25082 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2580 links (2111 relative) to 3391 anchors in 259 files [echo] Validated Links & Anchors via: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked [untar] Expanding: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/package/solr-8.2.0.tgz into /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings
[JENKINS] Lucene-Solr-Tests-master - Build # 3379 - Still unstable
Build: https://builds.apache.org/job/Lucene-Solr-Tests-master/3379/
1 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.sim.TestSimLargeCluster.testCreateLargeSimCollections
Error Message:
last ClusterState: znodeVersion: 1722 live nodes:[127.0.0.1:10082_solr,
127.0.0.1:10004_solr, 127.0.0.1:10018_solr, 127.0.0.1:10049_solr,
127.0.0.1:10020_solr, 127.0.0.1:10065_solr, 127.0.0.1:10021_solr,
127.0.0.1:10005_solr, 127.0.0.1:10066_solr, 127.0.0.1:10035_solr,
127.0.0.1:10051_solr, 127.0.0.1:10019_solr, 127.0.0.1:10096_solr,
127.0.0.1:10022_solr, 127.0.0.1:10033_solr, 127.0.0.1:10017_solr,
127.0.0.1:10047_solr, 127.0.0.1:10095_solr, 127.0.0.1:10081_solr,
127.0.0.1:10084_solr, 127.0.0.1:10036_solr, 127.0.0.1:10052_solr,
127.0.0.1:10006_solr, 127.0.0.1:10079_solr, 127.0.0.1:10098_solr,
127.0.0.1:10003_solr, 127.0.0.1:10001_solr, 127.0.0.1:10054_solr,
127.0.0.1:10099_solr, 127.0.0.1:10071_solr, 127.0.0.1:10023_solr,
127.0.0.1:10076_solr, 127.0.0.1:10007_solr, 127.0.0.1:10055_solr,
127.0.0.1:10010_solr, 127.0.0.1:10016_solr, 127.0.0.1:10070_solr,
127.0.0.1:10077_solr, 127.0.0.1:10038_solr, 127.0.0.1:10032_solr,
127.0.0.1:10093_solr, 127.0.0.1:10061_solr, 127.0.0.1:10067_solr,
127.0.0.1:10086_solr, 127.0.0.1:10089_solr, 127.0.0.1:10045_solr,
127.0.0.1:10042_solr, 127.0.0.1:10029_solr, 127.0.0.1:10083_solr,
127.0.0.1:10080_solr, 127.0.0.1:10048_solr, 127.0.0.1:10064_solr,
127.0.0.1:10043_solr, 127.0.0.1:10057_solr, 127.0.0.1:10074_solr,
127.0.0.1:10026_solr, 127.0.0.1:10012_solr, 127.0.0.1:10060_solr,
127.0.0.1:10073_solr, 127.0.0.1:10058_solr, 127.0.0.1:10013_solr,
127.0.0.1:10090_solr, 127.0.0.1:10088_solr, 127.0.0.1:10027_solr,
127.0.0.1:10039_solr, 127.0.0.1:10025_solr, 127.0.0.1:10044_solr,
127.0.0.1:10028_solr, 127.0.0.1:10092_solr, 127.0.0.1:10041_solr,
127.0.0.1:10087_solr, 127.0.0.1:10009_solr, 127.0.0.1:1_solr,
127.0.0.1:10030_solr, 127.0.0.1:10014_solr, 127.0.0.1:10011_solr,
127.0.0.1:10040_solr, 127.0.0.1:10085_solr, 127.0.0.1:10046_solr,
127.0.0.1:10068_solr, 127.0.0.1:10063_solr, 127.0.0.1:10015_solr,
127.0.0.1:10069_solr, 127.0.0.1:10062_solr, 127.0.0.1:10008_solr,
127.0.0.1:10024_solr, 127.0.0.1:10050_solr, 127.0.0.1:10075_solr,
127.0.0.1:10078_solr, 127.0.0.1:10002_solr, 127.0.0.1:10097_solr,
127.0.0.1:10031_solr, 127.0.0.1:10034_solr, 127.0.0.1:10091_solr,
127.0.0.1:10094_solr, 127.0.0.1:10037_solr, 127.0.0.1:10053_solr,
127.0.0.1:10059_solr, 127.0.0.1:10056_solr, 127.0.0.1:10072_solr]
collections:{large_sim_collection6=DocCollection(large_sim_collection6//clusterstate.json/1721)={
"replicationFactor":"1", "pullReplicas":"8",
"router":{"name":"compositeId"}, "maxShardsPerNode":"9",
"autoAddReplicas":"false", "nrtReplicas":"7", "tlogReplicas":"5",
"autoCreated":"true", "shards":{ "shard10":{ "replicas":{
"core_node191":{ "core":"large_sim_collection6_shard10_replica_t191",
"SEARCHER.searcher.maxDoc":0,
"SEARCHER.searcher.deletedDocs":0, "INDEX.sizeInBytes":10240,
"node_name":"127.0.0.1:10099_solr", "state":"active",
"type":"TLOG", "INDEX.sizeInGB":9.5367431640625E-6,
"SEARCHER.searcher.numDocs":0}, "core_node190":{
"core":"large_sim_collection6_shard10_replica_t190",
"SEARCHER.searcher.maxDoc":0, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240, "node_name":"127.0.0.1:10097_solr",
"state":"active", "type":"TLOG",
"INDEX.sizeInGB":9.5367431640625E-6, "SEARCHER.searcher.numDocs":0},
"core_node199":{
"core":"large_sim_collection6_shard10_replica_p199",
"SEARCHER.searcher.maxDoc":0, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240, "node_name":"127.0.0.1:10086_solr",
"state":"active", "type":"PULL",
"INDEX.sizeInGB":9.5367431640625E-6, "SEARCHER.searcher.numDocs":0},
"core_node188":{
"core":"large_sim_collection6_shard10_replica_t188",
"SEARCHER.searcher.maxDoc":0, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240, "node_name":"127.0.0.1:1_solr",
"state":"active", "type":"TLOG",
"INDEX.sizeInGB":9.5367431640625E-6, "SEARCHER.searcher.numDocs":0},
"core_node198":{
"core":"large_sim_collection6_shard10_replica_p198",
"SEARCHER.searcher.maxDoc":0, "SEARCHER.searcher.deletedDocs":0,
"INDEX.sizeInBytes":10240, "node_name":"127.0.0.1:10089_solr",
"state":"active", "type":"PULL",
"INDEX.sizeInGB":9.5367431640625E-6, "SEARCHER.searcher.numDocs":0},
"core_node187":{
"core":"large_sim_collection6_shard10_replica_n187",
"SEARCHER.searcher.maxDoc":0,
[JENKINS] Lucene-Solr-master-MacOSX (64bit/jdk-11.0.2) - Build # 5203 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-MacOSX/5203/
Java: 64bit/jdk-11.0.2 -XX:-UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 64907 lines...]
-ecj-javadoc-lint-tests:
[mkdir] Created dir:
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1961204052
[ecj-lint] Compiling 48 source files to
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj1961204052
[ecj-lint] invalid Class-Path header in manifest of jar file:
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. ERROR in
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
(at line 23)
[ecj-lint] import javax.naming.NamingException;
[ecj-lint]
[ecj-lint] The type javax.naming.NamingException is not accessible
[ecj-lint] --
[ecj-lint] 2. ERROR in
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
(at line 28)
[ecj-lint] public class MockInitialContextFactory implements
InitialContextFactory {
[ecj-lint] ^
[ecj-lint] The type MockInitialContextFactory must implement the inherited
abstract method InitialContextFactory.getInitialContext(Hashtable)
[ecj-lint] --
[ecj-lint] 3. ERROR in
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
(at line 30)
[ecj-lint] private final javax.naming.Context context;
[ecj-lint]
[ecj-lint] The type javax.naming.Context is not accessible
[ecj-lint] --
[ecj-lint] 4. ERROR in
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
(at line 33)
[ecj-lint] context = mock(javax.naming.Context.class);
[ecj-lint] ^^^
[ecj-lint] context cannot be resolved to a variable
[ecj-lint] --
[ecj-lint] 5. ERROR in
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
(at line 33)
[ecj-lint] context = mock(javax.naming.Context.class);
[ecj-lint]
[ecj-lint] The type javax.naming.Context is not accessible
[ecj-lint] --
[ecj-lint] 6. ERROR in
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
(at line 36)
[ecj-lint] when(context.lookup(anyString())).thenAnswer(invocation ->
objects.get(invocation.getArgument(0)));
[ecj-lint] ^^^
[ecj-lint] context cannot be resolved
[ecj-lint] --
[ecj-lint] 7. ERROR in
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
(at line 38)
[ecj-lint] } catch (NamingException e) {
[ecj-lint] ^^^
[ecj-lint] NamingException cannot be resolved to a type
[ecj-lint] --
[ecj-lint] 8. ERROR in
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
(at line 45)
[ecj-lint] public javax.naming.Context getInitialContext(Hashtable env) {
[ecj-lint]
[ecj-lint] The type javax.naming.Context is not accessible
[ecj-lint] --
[ecj-lint] 9. ERROR in
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/contrib/dataimporthandler/src/test/org/apache/solr/handler/dataimport/MockInitialContextFactory.java
(at line 46)
[ecj-lint] return context;
[ecj-lint]^^^
[ecj-lint] context cannot be resolved to a variable
[ecj-lint] --
[ecj-lint] 9 problems (9 errors)
BUILD FAILED
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:634: The following
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/build.xml:101: The following
error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/build.xml:651: The
following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/solr/common-build.xml:479:
The following error occurred while executing this line:
/Users/jenkins/workspace/Lucene-Solr-master-MacOSX/lucene/common-build.xml:2015:
The following error occurred while executing this line:
[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1872 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1872/ 2 tests failed. FAILED: org.apache.solr.cloud.RollingRestartTest.test Error Message: Timeout occurred while waiting response from server at: http://127.0.0.1:39161 Stack Trace: org.apache.solr.client.solrj.SolrServerException: Timeout occurred while waiting response from server at: http://127.0.0.1:39161 at __randomizedtesting.SeedInfo.seed([62F92A55875C823E:EAAD158F29A0EFC6]:0) at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:667) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:262) at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:245) at org.apache.solr.client.solrj.impl.LBSolrClient.doRequest(LBSolrClient.java:368) at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:296) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1068) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:837) at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:769) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:211) at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:228) at org.apache.solr.cloud.RollingRestartTest.restartWithRolesTest(RollingRestartTest.java:74) at org.apache.solr.cloud.RollingRestartTest.test(RollingRestartTest.java:53) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at
[JENKINS-EA] Lucene-Solr-BadApples-8.x-Linux (64bit/jdk-13-ea+18) - Build # 73 - Still Unstable!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-BadApples-8.x-Linux/73/
Java: 64bit/jdk-13-ea+18 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
1 tests failed.
FAILED: org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI
Error Message:
{} expected:<2> but was:<0>
Stack Trace:
java.lang.AssertionError: {} expected:<2> but was:<0>
at
__randomizedtesting.SeedInfo.seed([8F61B51A96E26E74:90B62936E5E9973F]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at
org.apache.solr.cloud.AliasIntegrationTest.testClusterStateProviderAPI(AliasIntegrationTest.java:303)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at java.base/java.lang.Thread.run(Thread.java:835)
Build Log:
[...truncated 2094 lines...]
[junit4] JVM J1: stderr was not empty, see:
