[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&focusedCommentId=16907193#comment-16907193 ] ASF subversion and git services commented on SOLR-13452: Commit 78427be5e617704aed756e1ea7d5306f161ffc22 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=78427be ] SOLR-13452: Fix JdepsReport method call. > 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) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > 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_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - 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&focusedCommentId=16907183#comment-16907183 ] ASF subversion and git services commented on SOLR-13452: Commit b6adfcbc3d9737f4d5d59dccd4808722682f442a in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b6adfcb ] SOLR-13452: Enable the test security manager and add some more missing sys props for setting up tests. > 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) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > 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_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets
[
https://issues.apache.org/jira/browse/LUCENE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906844#comment-16906844
]
ASF subversion and git services commented on LUCENE-8933:
-
Commit 0106b74badb98473e1e4464b8e2b37d7bebdc1a4 in lucene-solr's branch
refs/heads/branch_8x from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0106b74 ]
LUCENE-8933: Validate JapaneseTokenizer user dictionary entry (for 8.x) (#810)
> JapaneseTokenizer creates Token objects with corrupt offsets
>
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> An Elasticsearch user reported the following stack trace when parsing
> synonyms. It looks like the only reason why this might occur is if the offset
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
> ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f -
> nknize - 2018-12-07 14:44:20]
> at
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
> ~[?:?]
> at
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
> ~[elasticsearch-6.6.1.jar:6.6.1]
> at
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
> ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets
[
https://issues.apache.org/jira/browse/LUCENE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906841#comment-16906841
]
ASF subversion and git services commented on LUCENE-8933:
-
Commit cdeb294236388a52fa9cc38152da16ea0be057dd in lucene-solr's branch
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cdeb294 ]
LUCENE-8933: Use 'expectThrows' instead of 'expected'. (#830)
> JapaneseTokenizer creates Token objects with corrupt offsets
>
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> An Elasticsearch user reported the following stack trace when parsing
> synonyms. It looks like the only reason why this might occur is if the offset
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
> ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f -
> nknize - 2018-12-07 14:44:20]
> at
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
> ~[?:?]
> at
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
> ~[elasticsearch-6.6.1.jar:6.6.1]
> at
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
> ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
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&focusedCommentId=16906836#comment-16906836 ] ASF subversion and git services commented on SOLR-13452: Commit e45f99ebb8f03440b0985406ec188a81d320bf6b in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e45f99e ] SOLR-13452: Remove this test, Uwe says it's no longer relevant. > 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) > > Attachments: gradle-build.pdf > > Time Spent: 10m > Remaining Estimate: 0h > > 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_5 -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets
[
https://issues.apache.org/jira/browse/LUCENE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906820#comment-16906820
]
ASF subversion and git services commented on LUCENE-8933:
-
Commit 73ba88a50dec64f367caa88d277c26dfd1d8883b in lucene-solr's branch
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=73ba88a ]
LUCENE-8933: Validate JapaneseTokenizer user dictionary entry (#809)
* LUCENE-8933: Validate JapaneseTokenizer user dictionary entry if the
concatenated segment is same as its surface form.
> JapaneseTokenizer creates Token objects with corrupt offsets
>
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> An Elasticsearch user reported the following stack trace when parsing
> synonyms. It looks like the only reason why this might occur is if the offset
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
> ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f -
> nknize - 2018-12-07 14:44:20]
> at
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
> ~[?:?]
> at
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
> ~[elasticsearch-6.6.1.jar:6.6.1]
> at
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
> ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8933) JapaneseTokenizer creates Token objects with corrupt offsets
[
https://issues.apache.org/jira/browse/LUCENE-8933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906819#comment-16906819
]
ASF subversion and git services commented on LUCENE-8933:
-
Commit 73ba88a50dec64f367caa88d277c26dfd1d8883b in lucene-solr's branch
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=73ba88a ]
LUCENE-8933: Validate JapaneseTokenizer user dictionary entry (#809)
* LUCENE-8933: Validate JapaneseTokenizer user dictionary entry if the
concatenated segment is same as its surface form.
> JapaneseTokenizer creates Token objects with corrupt offsets
>
>
> Key: LUCENE-8933
> URL: https://issues.apache.org/jira/browse/LUCENE-8933
> Project: Lucene - Core
> Issue Type: Bug
>Reporter: Adrien Grand
>Priority: Minor
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> An Elasticsearch user reported the following stack trace when parsing
> synonyms. It looks like the only reason why this might occur is if the offset
> of a {{org.apache.lucene.analysis.ja.Token}} is not within the expected range.
>
> {noformat}
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at
> org.apache.lucene.analysis.tokenattributes.CharTermAttributeImpl.copyBuffer(CharTermAttributeImpl.java:44)
> ~[lucene-core-7.6.0.jar:7.6.0 719cde97f84640faa1e3525690d262946571245f -
> nknize - 2018-12-07 14:44:20]
> at
> org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:486)
> ~[?:?]
> at
> org.apache.lucene.analysis.synonym.SynonymMap$Parser.analyze(SynonymMap.java:318)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.elasticsearch.index.analysis.ESSolrSynonymParser.analyze(ESSolrSynonymParser.java:57)
> ~[elasticsearch-6.6.1.jar:6.6.1]
> at
> org.apache.lucene.analysis.synonym.SolrSynonymParser.addInternal(SolrSynonymParser.java:114)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.apache.lucene.analysis.synonym.SolrSynonymParser.parse(SolrSynonymParser.java:70)
> ~[lucene-analyzers-common-7.6.0.jar:7.6.0
> 719cde97f84640faa1e3525690d262946571245f - nknize - 2018-12-07 14:44:48]
> at
> org.elasticsearch.index.analysis.SynonymTokenFilterFactory.buildSynonyms(SynonymTokenFilterFactory.java:154)
> ~[elasticsearch-6.6.1.jar:6.6.1]
> ... 24 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13688) Make the bin/solr export command to run one thread per shard
[ https://issues.apache.org/jira/browse/SOLR-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906741#comment-16906741 ] ASF subversion and git services commented on SOLR-13688: Commit 8be67aa4c401800233f5f2f0b7431bccaeef1633 in lucene-solr's branch refs/heads/branch_8x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8be67aa ] SOLR-13688: compile error on java 8 > Make the bin/solr export command to run one thread per shard > > > Key: SOLR-13688 > URL: https://issues.apache.org/jira/browse/SOLR-13688 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Fix For: 8.3 > > > This can be run in parallel with one dedicated thread for each shard and > (distrib=false) option > this will be the only option -- This message was sent by Atlassian JIRA (v7.6.14#76016) - 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&focusedCommentId=16906721#comment-16906721 ] ASF subversion and git services commented on SOLR-13452: Commit c052e84aa6416e27c8842c2552334efacea214b8 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c052e84 ] SOLR-13452: Clean up exclude defs. > 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) > > Attachments: gradle-build.pdf > > > 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.14#76016) - 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&focusedCommentId=16906727#comment-16906727 ] ASF subversion and git services commented on SOLR-13452: Commit 0436ab0f491c8bf9b9b7678d87dc21c8a598b45d in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0436ab0 ] SOLR-13452: Add some comments, use the build cache by default. > 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) > > Attachments: gradle-build.pdf > > > 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.14#76016) - 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&focusedCommentId=16906725#comment-16906725 ] ASF subversion and git services commented on SOLR-13452: Commit 107837293ba0aa40358f4571c9801add4a20e37c in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1078372 ] 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) > > Attachments: gradle-build.pdf > > > 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.14#76016) - 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&focusedCommentId=16906722#comment-16906722 ] ASF subversion and git services commented on SOLR-13452: Commit 22baaee57fb945f4f47ea55833ea77eb456d58a2 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=22baaee ] 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) > > Attachments: gradle-build.pdf > > > 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.14#76016) - 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&focusedCommentId=16906729#comment-16906729 ] ASF subversion and git services commented on SOLR-13452: Commit 1d7264dff79335655f9e8d8ceb09f71079a6a2ee in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1d7264d ] SOLR-13452: Finish work on the dep checking tasks so that they work on each module and from top level. > 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) > > Attachments: gradle-build.pdf > > > 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.14#76016) - 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&focusedCommentId=16906728#comment-16906728 ] ASF subversion and git services commented on SOLR-13452: Commit 4754bcd095cc575aba700b196ada40e323008fea in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4754bcd ] SOLR-13452: Get merged up master working again. > 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) > > Attachments: gradle-build.pdf > > > 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.14#76016) - 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&focusedCommentId=16906720#comment-16906720 ] ASF subversion and git services commented on SOLR-13452: Commit 3c81fce246765af0f2a0d3e93c9763e4bd16425b in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3c81fce ] SOLR-13452: Updates needed after merging to latest master. > 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) > > Attachments: gradle-build.pdf > > > 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.14#76016) - 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&focusedCommentId=16906726#comment-16906726 ] ASF subversion and git services commented on SOLR-13452: Commit 6fa2fac265e98a6563d7da25e2545ac28cf33205 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6fa2fac ] SOLR-13452: Move checks from constructor to execute. > 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) > > Attachments: gradle-build.pdf > > > 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.14#76016) - 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&focusedCommentId=16906724#comment-16906724 ] ASF subversion and git services commented on SOLR-13452: Commit 9dad4b859fdbbceac78f4701b01fc05b40858027 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9dad4b8 ] 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) > > Attachments: gradle-build.pdf > > > 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.14#76016) - 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&focusedCommentId=16906723#comment-16906723 ] ASF subversion and git services commented on SOLR-13452: Commit 46db519646d3b8a5abe9eac35e0ac23eabe01736 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle_5 from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=46db519 ] 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) > > Attachments: gradle-build.pdf > > > 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.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906272#comment-16906272
]
ASF subversion and git services commented on SOLR-13240:
Commit 4689fb8642df95eb4afecc62e7b8c97d6a63f051 in lucene-solr's branch
refs/heads/branch_8x from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4689fb8 ]
SOLR-13240: make operation-not-null checks consistent in
TestPolicy.testNodeLostMultipleReplica
(Richard Goodman via Christine Poerschke)
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.
[jira] [Commented] (SOLR-13240) UTILIZENODE action results in an exception
[
https://issues.apache.org/jira/browse/SOLR-13240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16906268#comment-16906268
]
ASF subversion and git services commented on SOLR-13240:
Commit 9e6047331b47a683b340d96fdcd00ca75e33e20c in lucene-solr's branch
refs/heads/master from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9e60473 ]
SOLR-13240: make operation-not-null checks consistent in
TestPolicy.testNodeLostMultipleReplica
(Richard Goodman via Christine Poerschke)
> UTILIZENODE action results in an exception
> --
>
> Key: SOLR-13240
> URL: https://issues.apache.org/jira/browse/SOLR-13240
> Project: Solr
> Issue Type: Bug
> Components: AutoScaling
>Affects Versions: 7.6
>Reporter: Hendrik Haddorp
>Priority: Major
> Attachments: SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch,
> SOLR-13240.patch, SOLR-13240.patch, SOLR-13240.patch, solr-solrj-7.5.0.jar
>
>
> When I invoke the UTILIZENODE action the REST call fails like this after it
> moved a few replicas:
> {
> "responseHeader":{
> "status":500,
> "QTime":40220},
> "Operation utilizenode caused
> exception:":"java.lang.IllegalArgumentException:java.lang.IllegalArgumentException:
> Comparison method violates its general contract!",
> "exception":{
> "msg":"Comparison method violates its general contract!",
> "rspCode":-1},
> "error":{
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","org.apache.solr.common.SolrException"],
> "msg":"Comparison method violates its general contract!",
> "trace":"org.apache.solr.common.SolrException: Comparison method violates
> its general contract!\n\tat
> org.apache.solr.client.solrj.SolrResponse.getException(SolrResponse.java:53)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:274)\n\tat
>
> org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:246)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)\n\tat
>
> org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:734)\n\tat
> org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:715)\n\tat
> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:496)\n\tat
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:377)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:323)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:533)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
>
> org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:531)\n\tat
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352)\n\tat
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260)\n\tat
>
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281)\n\tat
> org.eclipse.jetty.io.Fil
[jira] [Commented] (SOLR-13688) Make the bin/solr export command to run one thread per shard
[ https://issues.apache.org/jira/browse/SOLR-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905971#comment-16905971 ] ASF subversion and git services commented on SOLR-13688: Commit 03fd3d3923b65c9829c58f1bf24d5859cee6369e in lucene-solr's branch refs/heads/branch_8x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=03fd3d3 ] SOLR-13688: Run the bin/solr export command multithreaded > Make the bin/solr export command to run one thread per shard > > > Key: SOLR-13688 > URL: https://issues.apache.org/jira/browse/SOLR-13688 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > This can be run in parallel with one dedicated thread for each shard and > (distrib=false) option > this will be the only option -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13688) Make the bin/solr export command to run one thread per shard
[ https://issues.apache.org/jira/browse/SOLR-13688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905967#comment-16905967 ] ASF subversion and git services commented on SOLR-13688: Commit 07ca02b7375a9c2564aba4c905e880a32d16e1df in lucene-solr's branch refs/heads/master from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=07ca02b ] SOLR-13688: Run the bin/solr export command multithreaded > Make the bin/solr export command to run one thread per shard > > > Key: SOLR-13688 > URL: https://issues.apache.org/jira/browse/SOLR-13688 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > > This can be run in parallel with one dedicated thread for each shard and > (distrib=false) option > this will be the only option -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13464) Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading security config
[
https://issues.apache.org/jira/browse/SOLR-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905679#comment-16905679
]
ASF subversion and git services commented on SOLR-13464:
Commit 06dd37e907df860125dbcaeb7a90ce5d7de684a1 in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=06dd37e ]
SOLR-13464: Test work arounds
* Refactor existing work around in BasicAuthIntegrationTest up into
SolrCloudAuthTestCase for re-use in JWTAuthPluginIntegrationTest
* Simplify BasicAuthOnSingleNodeTest and PKIAuthenticationIntegrationTest to
use their existing (static) security settings on creation of MiniSolrCloud.
Since they no longer modify security.json once the nodes are alive, the issue
no longer affects them
(cherry picked from commit c7822c393e6affa77c233f9e8e9bf9d8aeb12578)
(cherry picked from commit 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7)
> Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading
> security config
> ---
>
> Key: SOLR-13464
> URL: https://issues.apache.org/jira/browse/SOLR-13464
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Priority: Major
>
> I've been investigating some sporadic and hard to reproduce test failures
> related to authentication in cloud mode, and i *think* (but have not directly
> verified) that the common cause is that after uses one of the
> {{/admin/auth...}} handlers to update some setting, there is an inherient and
> unpredictible delay (due to ZK watches) until every node in the cluster has
> had a chance to (re)load the new configuration and initialize the various
> security plugins with the new settings.
> Which means, if a test client does a POST to some node to add/change/remove
> some authn/authz settings, and then immediately hits the exact same node (or
> any other node) to test that the effects of those settings exist, there is no
> garuntee that they will have taken affect yet.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13464) Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading security config
[
https://issues.apache.org/jira/browse/SOLR-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905618#comment-16905618
]
ASF subversion and git services commented on SOLR-13464:
Commit 0291db44bc8e092f7cb2f577f0ac8ab6fa6a5fd7 in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0291db4 ]
SOLR-13464: fix javadoc typo that precommit somehow missed?
> Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading
> security config
> ---
>
> Key: SOLR-13464
> URL: https://issues.apache.org/jira/browse/SOLR-13464
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Priority: Major
>
> I've been investigating some sporadic and hard to reproduce test failures
> related to authentication in cloud mode, and i *think* (but have not directly
> verified) that the common cause is that after uses one of the
> {{/admin/auth...}} handlers to update some setting, there is an inherient and
> unpredictible delay (due to ZK watches) until every node in the cluster has
> had a chance to (re)load the new configuration and initialize the various
> security plugins with the new settings.
> Which means, if a test client does a POST to some node to add/change/remove
> some authn/authz settings, and then immediately hits the exact same node (or
> any other node) to test that the effects of those settings exist, there is no
> garuntee that they will have taken affect yet.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13464) Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading security config
[
https://issues.apache.org/jira/browse/SOLR-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905588#comment-16905588
]
ASF subversion and git services commented on SOLR-13464:
Commit c7822c393e6affa77c233f9e8e9bf9d8aeb12578 in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c7822c3 ]
SOLR-13464: Test work arounds
* Refactor existing work around in BasicAuthIntegrationTest up into
SolrCloudAuthTestCase for re-use in JWTAuthPluginIntegrationTest
* Simplify BasicAuthOnSingleNodeTest and PKIAuthenticationIntegrationTest to
use their existing (static) security settings on creation of MiniSolrCloud.
Since they no longer modify security.json once the nodes are alive, the issue
no longer affects them
> Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading
> security config
> ---
>
> Key: SOLR-13464
> URL: https://issues.apache.org/jira/browse/SOLR-13464
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Priority: Major
>
> I've been investigating some sporadic and hard to reproduce test failures
> related to authentication in cloud mode, and i *think* (but have not directly
> verified) that the common cause is that after uses one of the
> {{/admin/auth...}} handlers to update some setting, there is an inherient and
> unpredictible delay (due to ZK watches) until every node in the cluster has
> had a chance to (re)load the new configuration and initialize the various
> security plugins with the new settings.
> Which means, if a test client does a POST to some node to add/change/remove
> some authn/authz settings, and then immediately hits the exact same node (or
> any other node) to test that the effects of those settings exist, there is no
> garuntee that they will have taken affect yet.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13399) compositeId support for shard splitting
[ https://issues.apache.org/jira/browse/SOLR-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905562#comment-16905562 ] ASF subversion and git services commented on SOLR-13399: Commit 7fc5c0e07d3b9d0651f9ad31f36eb021a9be8195 in lucene-solr's branch refs/heads/branch_8x from Megan Carey [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7fc5c0e ] SOLR-13399: Adding splitByPrefix param to IndexSizeTrigger; some splitByPrefix test and code cleanup > compositeId support for shard splitting > --- > > Key: SOLR-13399 > URL: https://issues.apache.org/jira/browse/SOLR-13399 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13399.patch, SOLR-13399.patch, > SOLR-13399_testfix.patch, SOLR-13399_useId.patch, > ShardSplitTest.master.seed_AE04B5C9BA6E9A4.log.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Shard splitting does not currently have a way to automatically take into > account the actual distribution (number of documents) in each hash bucket > created by using compositeId hashing. > We should probably add a parameter *splitByPrefix* to the *SPLITSHARD* > command that would look at the number of docs sharing each compositeId prefix > and use that to create roughly equal sized buckets by document count rather > than just assuming an equal distribution across the entire hash range. > Like normal shard splitting, we should bias against splitting within hash > buckets unless necessary (since that leads to larger query fanout.) . Perhaps > this warrants a parameter that would control how much of a size mismatch is > tolerable before resorting to splitting within a bucket. > *allowedSizeDifference*? > To more quickly calculate the number of docs in each bucket, we could index > the prefix in a different field. Iterating over the terms for this field > would quickly give us the number of docs in each (i.e lucene keeps track of > the doc count for each term already.) Perhaps the implementation could be a > flag on the *id* field... something like *indexPrefixes* and poly-fields that > would cause the indexing to be automatically done and alleviate having to > pass in an additional field during indexing and during the call to > *SPLITSHARD*. This whole part is an optimization though and could be split > off into its own issue if desired. > > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13399) compositeId support for shard splitting
[ https://issues.apache.org/jira/browse/SOLR-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905544#comment-16905544 ] ASF subversion and git services commented on SOLR-13399: Commit 768ca7c5a7fe5fcd89f047275319eafe783eb96c in lucene-solr's branch refs/heads/master from Megan Carey [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=768ca7c ] SOLR-13399: Adding splitByPrefix param to IndexSizeTrigger; some splitByPrefix test and code cleanup > compositeId support for shard splitting > --- > > Key: SOLR-13399 > URL: https://issues.apache.org/jira/browse/SOLR-13399 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13399.patch, SOLR-13399.patch, > SOLR-13399_testfix.patch, SOLR-13399_useId.patch, > ShardSplitTest.master.seed_AE04B5C9BA6E9A4.log.txt > > Time Spent: 20m > Remaining Estimate: 0h > > Shard splitting does not currently have a way to automatically take into > account the actual distribution (number of documents) in each hash bucket > created by using compositeId hashing. > We should probably add a parameter *splitByPrefix* to the *SPLITSHARD* > command that would look at the number of docs sharing each compositeId prefix > and use that to create roughly equal sized buckets by document count rather > than just assuming an equal distribution across the entire hash range. > Like normal shard splitting, we should bias against splitting within hash > buckets unless necessary (since that leads to larger query fanout.) . Perhaps > this warrants a parameter that would control how much of a size mismatch is > tolerable before resorting to splitting within a bucket. > *allowedSizeDifference*? > To more quickly calculate the number of docs in each bucket, we could index > the prefix in a different field. Iterating over the terms for this field > would quickly give us the number of docs in each (i.e lucene keeps track of > the doc count for each term already.) Perhaps the implementation could be a > flag on the *id* field... something like *indexPrefixes* and poly-fields that > would cause the indexing to be automatically done and alleviate having to > pass in an additional field during indexing and during the call to > *SPLITSHARD*. This whole part is an optimization though and could be split > off into its own issue if desired. > > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13647) default solr.in.sh contains uncommented lines
[ https://issues.apache.org/jira/browse/SOLR-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905118#comment-16905118 ] ASF subversion and git services commented on SOLR-13647: Commit 5ecc6dfaf890a117f21873725eba81feb1586d95 in lucene-solr's branch refs/heads/branch_8x from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5ecc6df ] SOLR-13647: Default solr.in.sh contains incorrect default value (cherry picked from commit d468d71c030dba77fb7e6bed295e5766248a5944) > default solr.in.sh contains uncommented lines > - > > Key: SOLR-13647 > URL: https://issues.apache.org/jira/browse/SOLR-13647 > Project: Solr > Issue Type: Bug >Affects Versions: 8.1.1 >Reporter: John >Assignee: Jan Høydahl >Priority: Trivial > Fix For: 8.3 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > default version of this file should be completely commented > ENABLE_REMOTE_JMX_OPTS had defaults -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13647) default solr.in.sh contains uncommented lines
[ https://issues.apache.org/jira/browse/SOLR-13647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16905115#comment-16905115 ] ASF subversion and git services commented on SOLR-13647: Commit d468d71c030dba77fb7e6bed295e5766248a5944 in lucene-solr's branch refs/heads/master from Jan Høydahl [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d468d71 ] SOLR-13647: Default solr.in.sh contains incorrect default value > default solr.in.sh contains uncommented lines > - > > Key: SOLR-13647 > URL: https://issues.apache.org/jira/browse/SOLR-13647 > Project: Solr > Issue Type: Bug >Affects Versions: 8.1.1 >Reporter: John >Assignee: Jan Høydahl >Priority: Trivial > Fix For: 8.3 > > Time Spent: 50m > Remaining Estimate: 0h > > default version of this file should be completely commented > ENABLE_REMOTE_JMX_OPTS had defaults -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13568) Expand component should not cache group queries in the filter cache
[ https://issues.apache.org/jira/browse/SOLR-13568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904689#comment-16904689 ] ASF subversion and git services commented on SOLR-13568: Commit 5df5df9ec37c9fbaca9c0629482a95fb90c8d33b in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5df5df9 ] SOLR-13568: Precommit fail Java var until 9x. Fail var... (cherry picked from commit f6f1b4244c40e5665b20a2a8ef9852c6dd827cb2) > Expand component should not cache group queries in the filter cache > --- > > Key: SOLR-13568 > URL: https://issues.apache.org/jira/browse/SOLR-13568 > Project: Solr > Issue Type: Bug >Affects Versions: 7.7.2, 8.1.1 >Reporter: Ludovic Boutros >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently the expand component is creating queries (bit sets) from the > current page document ids. > These queries are sadly put in the filter cache. > This behavior floods the filter cache and it becomes inefficient. > Therefore, the group query should be wrapped in a query with its cache flag > disabled. > This is a tiny little thing to do. The PR will follow very soon. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13568) Expand component should not cache group queries in the filter cache
[ https://issues.apache.org/jira/browse/SOLR-13568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904688#comment-16904688 ] ASF subversion and git services commented on SOLR-13568: Commit f6f1b4244c40e5665b20a2a8ef9852c6dd827cb2 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f6f1b42 ] SOLR-13568: Precommit fail Java var until 9x. Fail var... > Expand component should not cache group queries in the filter cache > --- > > Key: SOLR-13568 > URL: https://issues.apache.org/jira/browse/SOLR-13568 > Project: Solr > Issue Type: Bug >Affects Versions: 7.7.2, 8.1.1 >Reporter: Ludovic Boutros >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently the expand component is creating queries (bit sets) from the > current page document ids. > These queries are sadly put in the filter cache. > This behavior floods the filter cache and it becomes inefficient. > Therefore, the group query should be wrapped in a query with its cache flag > disabled. > This is a tiny little thing to do. The PR will follow very soon. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13573) Add getters to SolrRangeQuery for lower and upper values
[ https://issues.apache.org/jira/browse/SOLR-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904647#comment-16904647 ] ASF subversion and git services commented on SOLR-13573: Commit a50927bac0642d7e2302f5218a21b228f2a61ad0 in lucene-solr's branch refs/heads/branch_8x from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a50927b ] SOLR-13573: Add SolrRangeQuery getters for bounds > Add getters to SolrRangeQuery for lower and upper values > > > Key: SOLR-13573 > URL: https://issues.apache.org/jira/browse/SOLR-13573 > Project: Solr > Issue Type: Improvement >Affects Versions: 7.7, 8.1.1 >Reporter: Brian Rhees >Priority: Minor > Attachments: SOLR-13573.patch > > > SolrRangeQuery has no getters for the lower/upper values once set (other than > calling toString). Adding getters will help users extract those values after > an object has been created. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13573) Add getters to SolrRangeQuery for lower and upper values
[ https://issues.apache.org/jira/browse/SOLR-13573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904640#comment-16904640 ] ASF subversion and git services commented on SOLR-13573: Commit 52f1108a0e5054340a5091fae2dafa76c8f7c8d9 in lucene-solr's branch refs/heads/master from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=52f1108 ] SOLR-13573: Add SolrRangeQuery getters for bounds > Add getters to SolrRangeQuery for lower and upper values > > > Key: SOLR-13573 > URL: https://issues.apache.org/jira/browse/SOLR-13573 > Project: Solr > Issue Type: Improvement >Affects Versions: 7.7, 8.1.1 >Reporter: Brian Rhees >Priority: Minor > Attachments: SOLR-13573.patch > > > SolrRangeQuery has no getters for the lower/upper values once set (other than > calling toString). Adding getters will help users extract those values after > an object has been created. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13593) Allow to specify analyzer components by their SPI names in schema definition
[
https://issues.apache.org/jira/browse/SOLR-13593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904591#comment-16904591
]
ASF subversion and git services commented on SOLR-13593:
Commit 9b986d268f3618d2137bbc8bd068a3db0d772049 in lucene-solr's branch
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9b986d2 ]
SOLR-13593: Allow to look up analyzer components by their SPI names in field
type configuration.
> Allow to specify analyzer components by their SPI names in schema definition
>
>
> Key: SOLR-13593
> URL: https://issues.apache.org/jira/browse/SOLR-13593
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
>Reporter: Tomoko Uchida
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Now each analysis factory has explicitely documented SPI name which is stored
> in the static "NAME" field (LUCENE-8778).
> Solr uses factories' simple class name in schema definition (like
> class="solr.WhitespaceTokenizerFactory"), but we should be able to also use
> more concise SPI names (like name="whitespace").
> e.g.:
> {code:xml}
>
>
>
> />
>
>
>
> {code}
> would be
> {code:xml}
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8948) Change "name" argument in ICU factories to "form"
[
https://issues.apache.org/jira/browse/LUCENE-8948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904563#comment-16904563
]
ASF subversion and git services commented on LUCENE-8948:
-
Commit 407ba89aad028a37cf5ec0f131b8773d394177c2 in lucene-solr's branch
refs/heads/master from Tomoko Uchida
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=407ba89 ]
LUCENE-8948: Change 'name' argument in ICU factories to 'form'.
> Change "name" argument in ICU factories to "form"
> -
>
> Key: LUCENE-8948
> URL: https://issues.apache.org/jira/browse/LUCENE-8948
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
>Reporter: Tomoko Uchida
>Priority: Minor
> Attachments: LUCENE-8948.patch
>
>
> {{o.a.l.a.icu.ICUNormalizer2CharFilterFactory}} and
> {{o.a.l.a.icu.ICUNormalizer2FilterFactory}} have "name" arguments to specify
> Unicode Normalization Form. The "name" is vague and it causes problem with
> SOLR-13593.
> "form" would be suitable here instead of "name".
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13680) Close Resources Properly
[ https://issues.apache.org/jira/browse/SOLR-13680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904378#comment-16904378 ] ASF subversion and git services commented on SOLR-13680: Commit 4ac23230a4de07a572c06b5511958abd363f81a1 in lucene-solr's branch refs/heads/branch_8x from Munendra S N [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4ac2323 ] SOLR-13680: use try-with-resource to close closeable resources closes #822 > Close Resources Properly > > > Key: SOLR-13680 > URL: https://issues.apache.org/jira/browse/SOLR-13680 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.2 >Reporter: Furkan KAMACI >Assignee: Munendra S N >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13680.patch, SOLR-13680.patch > > Time Spent: 20m > Remaining Estimate: 0h > > Files, streams or connections which implements Closeable or AutoCloseable > interface should be closed after use. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13680) Close Resources Properly
[ https://issues.apache.org/jira/browse/SOLR-13680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904367#comment-16904367 ] ASF subversion and git services commented on SOLR-13680: Commit 9546d8612ca050021db894fc8001134a6fdbf654 in lucene-solr's branch refs/heads/master from Munendra S N [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9546d86 ] SOLR-13680: use try-with-resource to close closeable resources closes #822 > Close Resources Properly > > > Key: SOLR-13680 > URL: https://issues.apache.org/jira/browse/SOLR-13680 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.2 >Reporter: Furkan KAMACI >Assignee: Munendra S N >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13680.patch, SOLR-13680.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Files, streams or connections which implements Closeable or AutoCloseable > interface should be closed after use. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904362#comment-16904362
]
ASF subversion and git services commented on SOLR-13682:
Commit 1c9e0b8644a6776933d37e7b5bb86cd905195207 in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1c9e0b8 ]
SOLR-13682: command line option to export documents to a file
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904360#comment-16904360
]
ASF subversion and git services commented on SOLR-13682:
Commit aec2eb0c9da8fe9a45db74c7e0b8bd291d7def86 in lucene-solr's branch
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=aec2eb0 ]
SOLR-13682: command line option to export documents to a file
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904357#comment-16904357
]
ASF subversion and git services commented on SOLR-13682:
Commit b9912411ea32260989941d52295f7f88a1fe1157 in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b991241 ]
SOLR-13682: precommit errors
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904350#comment-16904350
]
ASF subversion and git services commented on SOLR-13682:
Commit 184a52ce045f70977206dde2a7e8945710abe358 in lucene-solr's branch
refs/heads/jira/SOLR-13682 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=184a52c ]
SOLR-13682: command line option to export documents to a file
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904348#comment-16904348
]
ASF subversion and git services commented on SOLR-13682:
Commit e45e8127d5c17af4e4b87a0a4eaf0afaf4f9ff4b in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e45e812 ]
SOLR-13682: command line option to export documents to a file
* SOLR-13682: command line option to export documents to a file
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904349#comment-16904349
]
ASF subversion and git services commented on SOLR-13682:
Commit e45e8127d5c17af4e4b87a0a4eaf0afaf4f9ff4b in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e45e812 ]
SOLR-13682: command line option to export documents to a file
* SOLR-13682: command line option to export documents to a file
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904347#comment-16904347
]
ASF subversion and git services commented on SOLR-13682:
Commit eea483a1daff14aa94844a3426c2ea55693193ef in lucene-solr's branch
refs/heads/jira/SOLR-13682 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=eea483a ]
SOLR-13682: added ref guide
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16904297#comment-16904297
]
ASF subversion and git services commented on SOLR-13682:
Commit a1712fdd58e936bf3460b3062c464a8a1fff1bff in lucene-solr's branch
refs/heads/jira/SOLR-13682 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a1712fd ]
SOLR-13682: with testcase
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> * {{limit}} : no:of docs. default is 100 , send {{-1}} to import all the
> docs
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/gettingstarted/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin
> http://localhost:7574/solr/gettingstarted/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13399) compositeId support for shard splitting
[ https://issues.apache.org/jira/browse/SOLR-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903868#comment-16903868 ] ASF subversion and git services commented on SOLR-13399: Commit 0fa9cb54c7c5ceefc9a709f3fbe753db9ab39f97 in lucene-solr's branch refs/heads/branch_8x from Yonik Seeley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0fa9cb5 ] SOLR-13399: fix splitByPrefix default to be false > compositeId support for shard splitting > --- > > Key: SOLR-13399 > URL: https://issues.apache.org/jira/browse/SOLR-13399 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13399.patch, SOLR-13399.patch, > SOLR-13399_testfix.patch, SOLR-13399_useId.patch, > ShardSplitTest.master.seed_AE04B5C9BA6E9A4.log.txt > > > Shard splitting does not currently have a way to automatically take into > account the actual distribution (number of documents) in each hash bucket > created by using compositeId hashing. > We should probably add a parameter *splitByPrefix* to the *SPLITSHARD* > command that would look at the number of docs sharing each compositeId prefix > and use that to create roughly equal sized buckets by document count rather > than just assuming an equal distribution across the entire hash range. > Like normal shard splitting, we should bias against splitting within hash > buckets unless necessary (since that leads to larger query fanout.) . Perhaps > this warrants a parameter that would control how much of a size mismatch is > tolerable before resorting to splitting within a bucket. > *allowedSizeDifference*? > To more quickly calculate the number of docs in each bucket, we could index > the prefix in a different field. Iterating over the terms for this field > would quickly give us the number of docs in each (i.e lucene keeps track of > the doc count for each term already.) Perhaps the implementation could be a > flag on the *id* field... something like *indexPrefixes* and poly-fields that > would cause the indexing to be automatically done and alleviate having to > pass in an additional field during indexing and during the call to > *SPLITSHARD*. This whole part is an optimization though and could be split > off into its own issue if desired. > > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13399) compositeId support for shard splitting
[ https://issues.apache.org/jira/browse/SOLR-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903866#comment-16903866 ] ASF subversion and git services commented on SOLR-13399: Commit 2e5c554fea0aea1dfeecb22f03f18fb78cd4 in lucene-solr's branch refs/heads/master from Yonik Seeley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2e5c554 ] SOLR-13399: fix splitByPrefix default to be false > compositeId support for shard splitting > --- > > Key: SOLR-13399 > URL: https://issues.apache.org/jira/browse/SOLR-13399 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13399.patch, SOLR-13399.patch, > SOLR-13399_testfix.patch, SOLR-13399_useId.patch, > ShardSplitTest.master.seed_AE04B5C9BA6E9A4.log.txt > > > Shard splitting does not currently have a way to automatically take into > account the actual distribution (number of documents) in each hash bucket > created by using compositeId hashing. > We should probably add a parameter *splitByPrefix* to the *SPLITSHARD* > command that would look at the number of docs sharing each compositeId prefix > and use that to create roughly equal sized buckets by document count rather > than just assuming an equal distribution across the entire hash range. > Like normal shard splitting, we should bias against splitting within hash > buckets unless necessary (since that leads to larger query fanout.) . Perhaps > this warrants a parameter that would control how much of a size mismatch is > tolerable before resorting to splitting within a bucket. > *allowedSizeDifference*? > To more quickly calculate the number of docs in each bucket, we could index > the prefix in a different field. Iterating over the terms for this field > would quickly give us the number of docs in each (i.e lucene keeps track of > the doc count for each term already.) Perhaps the implementation could be a > flag on the *id* field... something like *indexPrefixes* and poly-fields that > would cause the indexing to be automatically done and alleviate having to > pass in an additional field during indexing and during the call to > *SPLITSHARD*. This whole part is an optimization though and could be split > off into its own issue if desired. > > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903567#comment-16903567
]
ASF subversion and git services commented on SOLR-13682:
Commit acc3e47218c11a26839ad912e600294db2d0fda8 in lucene-solr's branch
refs/heads/jira/SOLR-13682 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=acc3e47 ]
SOLR-13682: refactored and cleaned up
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
> h2. Importing using {{curl}}
> importing json file
> {code:java}
> curl -X POST -d @gettingstarted.json
> http://localhost:18983/solr/copy/update/json/docs?commit=true
> {code}
> importing javabin format file
> {code:java}
> curl -X POST --header "Content-Type: application/javabin" --data-binary
> @gettingstarted.javabin http://localhost:7574/solr/mycore/update?commit=true
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13141) CDCR bootstrap does not replicate index to the replicas of target cluster
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903518#comment-16903518
]
ASF subversion and git services commented on SOLR-13141:
Commit f4dc168301cf5d3b582209c1a9420420ff1c3d64 in lucene-solr's branch
refs/heads/branch_8x from Shalin Shekhar Mangar
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f4dc168 ]
SOLR-13141: CDCR bootstrap does not replicate index to the replicas of target
cluster.
The leader node on the target cluster will now increment its term after
bootstrap succeeds so that all replicas of this leader are forced to recover
and fetch the latest index from the leader.
(cherry picked from commit e59f41b6712b4feb9b810b34108a43281c33e515)
> CDCR bootstrap does not replicate index to the replicas of target cluster
> -
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13141.patch, SOLR-13141.patch, type 1 - replication
> wasnt working at all.txt, type 2 - only few documents were being
> replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13141) CDCR bootstrap does not replicate index to the replicas of target cluster
[
https://issues.apache.org/jira/browse/SOLR-13141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903517#comment-16903517
]
ASF subversion and git services commented on SOLR-13141:
Commit e59f41b6712b4feb9b810b34108a43281c33e515 in lucene-solr's branch
refs/heads/master from Shalin Shekhar Mangar
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e59f41b ]
SOLR-13141: CDCR bootstrap does not replicate index to the replicas of target
cluster.
The leader node on the target cluster will now increment its term after
bootstrap succeeds so that all replicas of this leader are forced to recover
and fetch the latest index from the leader.
> CDCR bootstrap does not replicate index to the replicas of target cluster
> -
>
> Key: SOLR-13141
> URL: https://issues.apache.org/jira/browse/SOLR-13141
> Project: Solr
> Issue Type: Bug
> Components: CDCR
>Affects Versions: 7.5, 7.6
> Environment: This is system independent problem - exists on windows
> and linux - reproduced by independent developers
>Reporter: Krzysztof Watral
>Assignee: Shalin Shekhar Mangar
>Priority: Critical
> Fix For: master (9.0), 8.3
>
> Attachments: SOLR-13141.patch, SOLR-13141.patch, type 1 - replication
> wasnt working at all.txt, type 2 - only few documents were being
> replicated.txt
>
>
> i have encountered some problems with CDCR that are related to the value of
> {{replicationFactor}} param.
> I ran the solr cloud on two datacenters with 2 nodes on each:
> * dca:
> ** dca_node_1
> ** dca_node_2
> * dcb
> ** dcb_node_1
> ** dcb_node_2
> Then in sequence:
> * I configured the CDCR on copy of *_default* config set named
> *_default_cdcr*
> * I created collection "customer" on both DC from *_default_cdcr* config set
> with the following parameters:
> ** {{numShards}} = 2
> ** {{maxShardsPerNode}} = 2
> ** {{replicationFactor}} = 2
> * I disabled cdcr buffer on collections
> * I ran CDCR on both DC
> CDCR has started without errors in logs. During indexation I have encountered
> problem [^type 2 - only few documents were being replicated.txt], restart
> didn't help (documents has not been synchronized between DC )
> Then:
> * I stopped CDCR on both DC
> * I stopped all solr nodes
> * I restarted zookeepers on both DC
> * I started all solr nodes one by one
> * few minutes later I stared CDCR on both DC
> * CDCR has starded with errors (replication between DC is not working) -
> [^type 1 - replication wasnt working at all.txt]
> {panel}
> I've also discovered that problems appears only in case, when the
> {{replicationFactor}} parameter is higher than one
> {panel}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
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&focusedCommentId=16903403#comment-16903403
]
ASF subversion and git services commented on SOLR-13105:
Commit fb93340bf110fbdf98237dc67fda1446f0a6894f in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fb93340 ]
SOLR-13105: More loading changes 2
> 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.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8934) Move Nori DictionaryBuilder tool from src/tools to src/
[
https://issues.apache.org/jira/browse/LUCENE-8934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903090#comment-16903090
]
ASF subversion and git services commented on LUCENE-8934:
-
Commit 2677ee2955062f91074c759daf953b2ebcd39b6c in lucene-solr's branch
refs/heads/branch_8x from Namgyu Kim
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2677ee2 ]
LUCENE-8934: promote nori tools to main jar
> Move Nori DictionaryBuilder tool from src/tools to src/
> ---
>
> Key: LUCENE-8934
> URL: https://issues.apache.org/jira/browse/LUCENE-8934
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Namgyu Kim
>Assignee: Namgyu Kim
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> After LUCENE-8904 tests in Nori tools are not running in the normal test
> ({{ant test}}).
> As with Kuromoji(before LUCENE-8871), we need to run the {{ant test-tools}}
> to test Nori's tools.
> Like Kuromoji, we can proceed with the normality test after moving the tools
> of Nori to the main source tree.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8912) Remove ICU dependency of nori tools/test-tools
[
https://issues.apache.org/jira/browse/LUCENE-8912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903080#comment-16903080
]
ASF subversion and git services commented on LUCENE-8912:
-
Commit 2cabbf81524fc3e94e53a7a3f00c7419d484c838 in lucene-solr's branch
refs/heads/branch_8x from Namgyu Kim
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2cabbf8 ]
LUCENE-8912: remove nori/tools dependency on ICU
> Remove ICU dependency of nori tools/test-tools
> --
>
> Key: LUCENE-8912
> URL: https://issues.apache.org/jira/browse/LUCENE-8912
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Namgyu Kim
>Assignee: Namgyu Kim
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {quote}After this job, I'll apply LUCENE-8866 and LUCENE-8871 to Nori.
> {quote}
> As mentioned in LUCENE-8904, I proceed this work from now on.
> It is what [~rcmuir] found first(LUCENE-8866) and then I just apply to Nori.
> Nori doesn't need the ICU library because it uses Normalizer2 only for NFKC
> normalization like Kuromoji.
> I think it's OK to remove the library dependency because it can be handled
> by JDK.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8904) Enhance Nori DictionaryBuilder tool
[ https://issues.apache.org/jira/browse/LUCENE-8904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903053#comment-16903053 ] ASF subversion and git services commented on LUCENE-8904: - Commit 70854dc1efbdc1d7efdb8ac0421c69d36ea6e31f in lucene-solr's branch refs/heads/branch_8x from Namgyu Kim [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=70854dc ] LUCENE-8904: enhance Nori DictionaryBuilder tool > Enhance Nori DictionaryBuilder tool > --- > > Key: LUCENE-8904 > URL: https://issues.apache.org/jira/browse/LUCENE-8904 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Namgyu Kim >Assignee: Namgyu Kim >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > It is the Nori version of [~sokolov]'s LUCENE-8863. > This patch has two changes. > 1) Improve exception handling > 2) Enable external dictionary for testing > Overall, it is the same as LUCENE-8863. > But there are some differences between Nori and Kuromoji. > These can be slightly different on the code. > 1) CSV field size > Nori : 12 > Kuromoji : 13 > 2) left context ID == right context ID > Nori : can be different > Kuromoji : always same > 3) Dictionary Type > Nori : just one type > Kuromoji : IPADIC, UNIDIC > After this job, I'll apply LUCENE-8866 and LUCENE-8871 to Nori. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16903011#comment-16903011
]
ASF subversion and git services commented on SOLR-13682:
Commit 88b3becaa5b79aafe497ff58758958715ba354fa in lucene-solr's branch
refs/heads/jira/SOLR-13682 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=88b3bec ]
SOLR-13682: support for fields, query etc
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export -url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.json}}
> additional options are
> * {{format}} : {{jsonl}} (default) or {{javabin}}
> * {{out}} : export file name .(if this starts with "http://"; the output will
> be piped to that url. Can be used to pipe docs to another cluster)
> * {{query}} : a custom query , default is **:**
> * {{fields}}: a comma separated list of fields to be exported
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
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&focusedCommentId=16903004#comment-16903004
]
ASF subversion and git services commented on SOLR-13105:
Commit 30826335233d5ad37f51fcbf13f0169a47eb1e7d in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3082633 ]
SOLR-13105: More loading changes
> 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.14#76016)
-
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&focusedCommentId=16902942#comment-16902942
]
ASF subversion and git services commented on SOLR-13105:
Commit 05ef5d74214188973c151acdf7cbed0a2e1a577a in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=05ef5d7 ]
SOLR-13105: Add text to loading page 9
> 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.14#76016)
-
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&focusedCommentId=16902943#comment-16902943
]
ASF subversion and git services commented on SOLR-13105:
Commit a594a091e98937293758fa91f518b8564712fe50 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a594a09 ]
SOLR-13105: Add analyze docs for data load
> 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.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16902931#comment-16902931 ] ASF subversion and git services commented on SOLR-13622: Commit 299d92da5cc6315a98ef656a66ab7b285ecb4e3d in lucene-solr's branch refs/heads/branch_8x from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=299d92d ] SOLR-13622: Rename FilesStream -> CatStream Also fixes an 'cat' OS-dependent bug in StreamExpressionTest. > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13622.patch, SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13622) Add FileStream Streaming Expression
[ https://issues.apache.org/jira/browse/SOLR-13622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16902930#comment-16902930 ] ASF subversion and git services commented on SOLR-13622: Commit 2eb493d1700d59845ac120dcc485556b7e7fb422 in lucene-solr's branch refs/heads/master from Jason Gerlowski [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2eb493d ] SOLR-13622: Rename FilesStream -> CatStream Also fixes an 'cat' OS-dependent bug in StreamExpressionTest. > Add FileStream Streaming Expression > --- > > Key: SOLR-13622 > URL: https://issues.apache.org/jira/browse/SOLR-13622 > Project: Solr > Issue Type: New Feature > Components: streaming expressions >Reporter: Joel Bernstein >Assignee: Jason Gerlowski >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13622.patch, SOLR-13622.patch > > > The FileStream will read files from a local filesystem and Stream back each > line of the file as a tuple. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13674) NodeAddedTrigger does not support configuration of replica type hint
[ https://issues.apache.org/jira/browse/SOLR-13674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16902837#comment-16902837 ] ASF subversion and git services commented on SOLR-13674: Commit de522052c8b113a90613055585c864aa7bcdb300 in lucene-solr's branch refs/heads/branch_8x from Shalin Shekhar Mangar [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=de52205 ] SOLR-13674: NodeAddedTrigger does not support configuration of replica type hint. A new replicaType property has been added to NodeAddTrigger so that new replicas of the given type are added when the preferredOp is addreplica. The default value of replicaType is `NRT`. This closes #821. (cherry picked from commit ed137dbe281cfb314af340673a7b646922a2e7d1) > NodeAddedTrigger does not support configuration of replica type hint > > > Key: SOLR-13674 > URL: https://issues.apache.org/jira/browse/SOLR-13674 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 >Reporter: Irena Shaigorodsky >Assignee: Shalin Shekhar Mangar >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The current code > org.apache.solr.cloud.autoscaling.ComputePlanAction#getNodeAddedSuggester > only sets COLL_SHARD hint, as a result any added replica will be NRT one. > Our current setup has TLOG nodes on physical hardware and PULL nodes on k8s > that are recycled periodically. An attempt to add those will bring the nodes > in the cluster as NRT one. > The root cause is > org.apache.solr.client.solrj.cloud.autoscaling.AddReplicaSuggester#tryEachNode > that expects to find the hint REPLICATYPE and defaults to NRT one. > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13674) NodeAddedTrigger does not support configuration of replica type hint
[ https://issues.apache.org/jira/browse/SOLR-13674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16902834#comment-16902834 ] ASF subversion and git services commented on SOLR-13674: Commit ed137dbe281cfb314af340673a7b646922a2e7d1 in lucene-solr's branch refs/heads/master from Shalin Shekhar Mangar [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ed137db ] SOLR-13674: NodeAddedTrigger does not support configuration of replica type hint. A new replicaType property has been added to NodeAddTrigger so that new replicas of the given type are added when the preferredOp is addreplica. The default value of replicaType is `NRT`. This closes #821. > NodeAddedTrigger does not support configuration of replica type hint > > > Key: SOLR-13674 > URL: https://issues.apache.org/jira/browse/SOLR-13674 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 7.6 >Reporter: Irena Shaigorodsky >Assignee: Shalin Shekhar Mangar >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The current code > org.apache.solr.cloud.autoscaling.ComputePlanAction#getNodeAddedSuggester > only sets COLL_SHARD hint, as a result any added replica will be NRT one. > Our current setup has TLOG nodes on physical hardware and PULL nodes on k8s > that are recycled periodically. An attempt to add those will bring the nodes > in the cluster as NRT one. > The root cause is > org.apache.solr.client.solrj.cloud.autoscaling.AddReplicaSuggester#tryEachNode > that expects to find the hint REPLICATYPE and defaults to NRT one. > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16902827#comment-16902827
]
ASF subversion and git services commented on SOLR-13682:
Commit 007809cab7a8407a431d2e988a9c78655ffdbf62 in lucene-solr's branch
refs/heads/jira/SOLR-13682 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=007809c ]
SOLR-13682: command line option to export data to a file
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export --url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.javabin}}
> additional options are
> * format : jsonl or javabin
> * out : export file name
> * .(if this starts with "http://"; the output will be piped to that url. Can
> be used to pipe docs to another cluster)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16902818#comment-16902818
]
ASF subversion and git services commented on SOLR-13682:
Commit 08daf37d7226ce3630187fbec7e1c1227029e364 in lucene-solr's branch
refs/heads/jira/SOLR-13682 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=08daf37 ]
SOLR-13682: command line option to export data to a file
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code:java}
> bin/solr export --url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.javabin}}
> additional options are
> * format : jsonl or javabin
> * out : export file name
> * .(if this starts with "http://"; the output will be piped to that url. Can
> be used to pipe docs to another cluster)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13682) command line option to export data to a file
[
https://issues.apache.org/jira/browse/SOLR-13682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16902777#comment-16902777
]
ASF subversion and git services commented on SOLR-13682:
Commit 696f83df963d296d2cf2b639d2d5d1c5c317edd0 in lucene-solr's branch
refs/heads/jira/SOLR-13682 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=696f83d ]
SOLR-13682: command line option to export data to a file
> command line option to export data to a file
>
>
> Key: SOLR-13682
> URL: https://issues.apache.org/jira/browse/SOLR-13682
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> example
> {code}
> bin/solr export --url http://localhost:8983/solr/gettingstarted
> {code}
> This will export all the docs in a collection called {{gettingstarted}} into
> a file called {{gettingstarted.javabin}}
> additional options are
> * format : jsonl or javabin
> * file : export file name .(if this starts with "http://"; the output will be
> piped to that url. Can be used to pipe docs to another cluster)
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
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&focusedCommentId=16902047#comment-16902047
]
ASF subversion and git services commented on SOLR-13105:
Commit 1645075b5f64aad9a26f67dd65adf7167ee04366 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1645075 ]
SOLR-13105: Add text to loading page 8
> 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.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16902040#comment-16902040 ] ASF subversion and git services commented on SOLR-13677: Commit 9b0003a7037206d937b9f4aa48e5dc4cf80fdd0f in lucene-solr's branch refs/heads/jira/SOLR-13677_1 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9b0003a ] SOLR-13677: Take 2 > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8747) Allow access to submatches from Matches instances
[ https://issues.apache.org/jira/browse/LUCENE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901976#comment-16901976 ] ASF subversion and git services commented on LUCENE-8747: - Commit 21842999fe559bcbb4aebf7504aee6e8db45b38e in lucene-solr's branch refs/heads/master from Alan Woodward [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2184299 ] LUCENE-8747: Allow access to submatches from Matches > Allow access to submatches from Matches instances > - > > Key: LUCENE-8747 > URL: https://issues.apache.org/jira/browse/LUCENE-8747 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8747.patch, LUCENE-8747.patch, LUCENE-8747.patch, > LUCENE-8747.patch, LUCENE-8747.patch > > > A Matches object currently allows access to all matching terms from a query, > but the structure of the matching query is flattened out, so if you want to > find which subqueries have matched you need to iterate over all matches, > collecting queries as you go. It should be easier to get this information > from the parent Matches object. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8747) Allow access to submatches from Matches instances
[ https://issues.apache.org/jira/browse/LUCENE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901974#comment-16901974 ] ASF subversion and git services commented on LUCENE-8747: - Commit 8dd116a615821c7d9b539316b051f466009b5130 in lucene-solr's branch refs/heads/branch_8x from Alan Woodward [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8dd116a ] LUCENE-8747: Allow access to submatches from Matches > Allow access to submatches from Matches instances > - > > Key: LUCENE-8747 > URL: https://issues.apache.org/jira/browse/LUCENE-8747 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8747.patch, LUCENE-8747.patch, LUCENE-8747.patch, > LUCENE-8747.patch, LUCENE-8747.patch > > > A Matches object currently allows access to all matching terms from a query, > but the structure of the matching query is flattened out, so if you want to > find which subqueries have matched you need to iterate over all matches, > collecting queries as you go. It should be easier to get this information > from the parent Matches object. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8941) Build wildcard matches more lazily
[ https://issues.apache.org/jira/browse/LUCENE-8941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901975#comment-16901975 ] ASF subversion and git services commented on LUCENE-8941: - Commit fa72da1c7112a2e5c259f1f0181e6b27766ed4ad in lucene-solr's branch refs/heads/master from Alan Woodward [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fa72da1 ] LUCENE-8941: Build wildcard matches lazily > Build wildcard matches more lazily > -- > > Key: LUCENE-8941 > URL: https://issues.apache.org/jira/browse/LUCENE-8941 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8941.patch, LUCENE-8941.patch > > > When retrieving a Matches object from a multi-term query, such as an > AutomatonQuery or TermInSetQuery, we currently find all matching term > iterators up-front, to return a disjunction over all of them. This can be > inefficient if we're only interested in finding out if anything matched, and > are iterating over a different field to retrieve offsets. > We can improve this by returning immediately when the first matching term is > found, and only collecting other matching terms when we start iterating. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8941) Build wildcard matches more lazily
[ https://issues.apache.org/jira/browse/LUCENE-8941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901973#comment-16901973 ] ASF subversion and git services commented on LUCENE-8941: - Commit b5b78e0adeb9db9345b69abedabd8c5cd684df7b in lucene-solr's branch refs/heads/branch_8x from Alan Woodward [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b5b78e0 ] LUCENE-8941: Build wildcard matches lazily > Build wildcard matches more lazily > -- > > Key: LUCENE-8941 > URL: https://issues.apache.org/jira/browse/LUCENE-8941 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Major > Attachments: LUCENE-8941.patch, LUCENE-8941.patch > > > When retrieving a Matches object from a multi-term query, such as an > AutomatonQuery or TermInSetQuery, we currently find all matching term > iterators up-front, to return a disjunction over all of them. This can be > inefficient if we're only interested in finding out if anything matched, and > are iterating over a different field to retrieve offsets. > We can improve this by returning immediately when the first matching term is > found, and only collecting other matching terms when we start iterating. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13672) Admin UI/ZK Status page: Zookeeper 3.5 : 4lw.commands.whitellist error
[
https://issues.apache.org/jira/browse/SOLR-13672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901852#comment-16901852
]
ASF subversion and git services commented on SOLR-13672:
Commit f853198f72f802611c3e0ee8882cdd6a80a818aa in lucene-solr's branch
refs/heads/branch_8x from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f853198 ]
SOLR-13672: Cloud -> Zk Status page now parses response from Zookeeper 3.5.5
correctly
(Back ported from 8 commits on master branch)
> Admin UI/ZK Status page: Zookeeper 3.5 : 4lw.commands.whitellist error
> --
>
> Key: SOLR-13672
> URL: https://issues.apache.org/jira/browse/SOLR-13672
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.2
>Reporter: Jörn Franke
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: 8.3
>
> Attachments: SOLR-13672.patch, zk-status.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After upgrading to Solr 8.2 and Zookeeper 3.5.5 one sees the following error
> in the Admin UI / Cloud / ZkStatus:
> {color:#22}*"Errors: - membership: Check 4lw.commands.whitelist setting
> in zookeeper{color}
> {color:#22}configuration file."*{color}
> {color:#22}Aside of the UI, the Solr Cloud nodes seem to work perfectly
> normal.{color}
> {color:#22}This issue only occurs with ZooKeeper ensembles. It does not
> appear if one Zookeeper standalone instance is used.{color}
> {color:#22}We tried the 4lw.commands.whitelist with wildcard * and
> "mntr,conf,ruok" (with and without spaces).{color}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13672) Admin UI/ZK Status page: Zookeeper 3.5 : 4lw.commands.whitellist error
[
https://issues.apache.org/jira/browse/SOLR-13672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901800#comment-16901800
]
ASF subversion and git services commented on SOLR-13672:
Commit 64884be0444e3ed7ae2a0adce2689b03da934188 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=64884be ]
SOLR-13672: Zk Status page now parses response from Zookeeper 3.5.5 correctly
(#818)
* SOLR-13672: Cloud -> Zk Status page now parses response from Zookeeper 3.5.5
correctly
> Admin UI/ZK Status page: Zookeeper 3.5 : 4lw.commands.whitellist error
> --
>
> Key: SOLR-13672
> URL: https://issues.apache.org/jira/browse/SOLR-13672
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.2
>Reporter: Jörn Franke
>Priority: Major
> Attachments: SOLR-13672.patch, zk-status.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After upgrading to Solr 8.2 and Zookeeper 3.5.5 one sees the following error
> in the Admin UI / Cloud / ZkStatus:
> {color:#22}*"Errors: - membership: Check 4lw.commands.whitelist setting
> in zookeeper{color}
> {color:#22}configuration file."*{color}
> {color:#22}Aside of the UI, the Solr Cloud nodes seem to work perfectly
> normal.{color}
> {color:#22}This issue only occurs with ZooKeeper ensembles. It does not
> appear if one Zookeeper standalone instance is used.{color}
> {color:#22}We tried the 4lw.commands.whitelist with wildcard * and
> "mntr,conf,ruok" (with and without spaces).{color}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13672) Admin UI/ZK Status page: Zookeeper 3.5 : 4lw.commands.whitellist error
[
https://issues.apache.org/jira/browse/SOLR-13672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901799#comment-16901799
]
ASF subversion and git services commented on SOLR-13672:
Commit 64884be0444e3ed7ae2a0adce2689b03da934188 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=64884be ]
SOLR-13672: Zk Status page now parses response from Zookeeper 3.5.5 correctly
(#818)
* SOLR-13672: Cloud -> Zk Status page now parses response from Zookeeper 3.5.5
correctly
> Admin UI/ZK Status page: Zookeeper 3.5 : 4lw.commands.whitellist error
> --
>
> Key: SOLR-13672
> URL: https://issues.apache.org/jira/browse/SOLR-13672
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.2
>Reporter: Jörn Franke
>Priority: Major
> Attachments: SOLR-13672.patch, zk-status.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After upgrading to Solr 8.2 and Zookeeper 3.5.5 one sees the following error
> in the Admin UI / Cloud / ZkStatus:
> {color:#22}*"Errors: - membership: Check 4lw.commands.whitelist setting
> in zookeeper{color}
> {color:#22}configuration file."*{color}
> {color:#22}Aside of the UI, the Solr Cloud nodes seem to work perfectly
> normal.{color}
> {color:#22}This issue only occurs with ZooKeeper ensembles. It does not
> appear if one Zookeeper standalone instance is used.{color}
> {color:#22}We tried the 4lw.commands.whitelist with wildcard * and
> "mntr,conf,ruok" (with and without spaces).{color}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13672) Admin UI/ZK Status page: Zookeeper 3.5 : 4lw.commands.whitellist error
[
https://issues.apache.org/jira/browse/SOLR-13672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901798#comment-16901798
]
ASF subversion and git services commented on SOLR-13672:
Commit 1123afae94f36027bcb7b2dc40b089653ed4d1c8 in lucene-solr's branch
refs/heads/master from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1123afa ]
SOLR-13672: Cloud -> Zk Status page now parses response from Zookeeper 3.5.5
correctly
> Admin UI/ZK Status page: Zookeeper 3.5 : 4lw.commands.whitellist error
> --
>
> Key: SOLR-13672
> URL: https://issues.apache.org/jira/browse/SOLR-13672
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.2
>Reporter: Jörn Franke
>Priority: Major
> Attachments: SOLR-13672.patch, zk-status.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> After upgrading to Solr 8.2 and Zookeeper 3.5.5 one sees the following error
> in the Admin UI / Cloud / ZkStatus:
> {color:#22}*"Errors: - membership: Check 4lw.commands.whitelist setting
> in zookeeper{color}
> {color:#22}configuration file."*{color}
> {color:#22}Aside of the UI, the Solr Cloud nodes seem to work perfectly
> normal.{color}
> {color:#22}This issue only occurs with ZooKeeper ensembles. It does not
> appear if one Zookeeper standalone instance is used.{color}
> {color:#22}We tried the 4lw.commands.whitelist with wildcard * and
> "mntr,conf,ruok" (with and without spaces).{color}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
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&focusedCommentId=16901642#comment-16901642
]
ASF subversion and git services commented on SOLR-13105:
Commit 0451c6e5320f4350f8fc75baacdcc50d05151cf4 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0451c6e ]
SOLR-13105: Add text to loading page 7
> 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.14#76016)
-
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&focusedCommentId=16901637#comment-16901637
]
ASF subversion and git services commented on SOLR-13105:
Commit 893ca4b34c5bd29e2338eff42994a56e031b9ce6 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=893ca4b ]
SOLR-13105: Add text to loading page 6
> 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.14#76016)
-
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&focusedCommentId=16901611#comment-16901611
]
ASF subversion and git services commented on SOLR-13105:
Commit ae6287faff562df37369f04987172416d87b2744 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ae6287f ]
SOLR-13105: Add text to loading page 5
> 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.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13464) Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading security config
[
https://issues.apache.org/jira/browse/SOLR-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901523#comment-16901523
]
ASF subversion and git services commented on SOLR-13464:
Commit 6fea853711773a134c7b04b40a31193af5dd77f8 in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6fea853 ]
Harden BasicAuthIntegrationTest w/work around for SOLR-13464
(cherry picked from commit 878d332a0bd7374190a85a23d3a6241d930289f3)
> Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading
> security config
> ---
>
> Key: SOLR-13464
> URL: https://issues.apache.org/jira/browse/SOLR-13464
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Priority: Major
>
> I've been investigating some sporadic and hard to reproduce test failures
> related to authentication in cloud mode, and i *think* (but have not directly
> verified) that the common cause is that after uses one of the
> {{/admin/auth...}} handlers to update some setting, there is an inherient and
> unpredictible delay (due to ZK watches) until every node in the cluster has
> had a chance to (re)load the new configuration and initialize the various
> security plugins with the new settings.
> Which means, if a test client does a POST to some node to add/change/remove
> some authn/authz settings, and then immediately hits the exact same node (or
> any other node) to test that the effects of those settings exist, there is no
> garuntee that they will have taken affect yet.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13464) Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading security config
[
https://issues.apache.org/jira/browse/SOLR-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901516#comment-16901516
]
ASF subversion and git services commented on SOLR-13464:
Commit 878d332a0bd7374190a85a23d3a6241d930289f3 in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=878d332 ]
Harden BasicAuthIntegrationTest w/work around for SOLR-13464
> Sporadic Auth + Cloud test failures, probably due to lag in nodes reloading
> security config
> ---
>
> Key: SOLR-13464
> URL: https://issues.apache.org/jira/browse/SOLR-13464
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Priority: Major
>
> I've been investigating some sporadic and hard to reproduce test failures
> related to authentication in cloud mode, and i *think* (but have not directly
> verified) that the common cause is that after uses one of the
> {{/admin/auth...}} handlers to update some setting, there is an inherient and
> unpredictible delay (due to ZK watches) until every node in the cluster has
> had a chance to (re)load the new configuration and initialize the various
> security plugins with the new settings.
> Which means, if a test client does a POST to some node to add/change/remove
> some authn/authz settings, and then immediately hits the exact same node (or
> any other node) to test that the effects of those settings exist, there is no
> garuntee that they will have taken affect yet.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13399) compositeId support for shard splitting
[ https://issues.apache.org/jira/browse/SOLR-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901349#comment-16901349 ] ASF subversion and git services commented on SOLR-13399: Commit d8f99a9986835507d19b70edf0ff280416104788 in lucene-solr's branch refs/heads/branch_8x from Yonik Seeley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d8f99a9 ] SOLR-13399: ability to use id field for compositeId histogram > compositeId support for shard splitting > --- > > Key: SOLR-13399 > URL: https://issues.apache.org/jira/browse/SOLR-13399 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13399.patch, SOLR-13399.patch, > SOLR-13399_testfix.patch, SOLR-13399_useId.patch > > > Shard splitting does not currently have a way to automatically take into > account the actual distribution (number of documents) in each hash bucket > created by using compositeId hashing. > We should probably add a parameter *splitByPrefix* to the *SPLITSHARD* > command that would look at the number of docs sharing each compositeId prefix > and use that to create roughly equal sized buckets by document count rather > than just assuming an equal distribution across the entire hash range. > Like normal shard splitting, we should bias against splitting within hash > buckets unless necessary (since that leads to larger query fanout.) . Perhaps > this warrants a parameter that would control how much of a size mismatch is > tolerable before resorting to splitting within a bucket. > *allowedSizeDifference*? > To more quickly calculate the number of docs in each bucket, we could index > the prefix in a different field. Iterating over the terms for this field > would quickly give us the number of docs in each (i.e lucene keeps track of > the doc count for each term already.) Perhaps the implementation could be a > flag on the *id* field... something like *indexPrefixes* and poly-fields that > would cause the indexing to be automatically done and alleviate having to > pass in an additional field during indexing and during the call to > *SPLITSHARD*. This whole part is an optimization though and could be split > off into its own issue if desired. > > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13399) compositeId support for shard splitting
[ https://issues.apache.org/jira/browse/SOLR-13399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901348#comment-16901348 ] ASF subversion and git services commented on SOLR-13399: Commit 19ddcfd282f3b9eccc50da83653674e510229960 in lucene-solr's branch refs/heads/master from Yonik Seeley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=19ddcfd2 ] SOLR-13399: ability to use id field for compositeId histogram > compositeId support for shard splitting > --- > > Key: SOLR-13399 > URL: https://issues.apache.org/jira/browse/SOLR-13399 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Yonik Seeley >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13399.patch, SOLR-13399.patch, > SOLR-13399_testfix.patch, SOLR-13399_useId.patch > > > Shard splitting does not currently have a way to automatically take into > account the actual distribution (number of documents) in each hash bucket > created by using compositeId hashing. > We should probably add a parameter *splitByPrefix* to the *SPLITSHARD* > command that would look at the number of docs sharing each compositeId prefix > and use that to create roughly equal sized buckets by document count rather > than just assuming an equal distribution across the entire hash range. > Like normal shard splitting, we should bias against splitting within hash > buckets unless necessary (since that leads to larger query fanout.) . Perhaps > this warrants a parameter that would control how much of a size mismatch is > tolerable before resorting to splitting within a bucket. > *allowedSizeDifference*? > To more quickly calculate the number of docs in each bucket, we could index > the prefix in a different field. Iterating over the terms for this field > would quickly give us the number of docs in each (i.e lucene keeps track of > the doc count for each term already.) Perhaps the implementation could be a > flag on the *id* field... something like *indexPrefixes* and poly-fields that > would cause the indexing to be automatically done and alleviate having to > pass in an additional field during indexing and during the call to > *SPLITSHARD*. This whole part is an optimization though and could be split > off into its own issue if desired. > > -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8883) CHANGES.txt: Auto add issue categories on new releases
[ https://issues.apache.org/jira/browse/LUCENE-8883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900940#comment-16900940 ] ASF subversion and git services commented on LUCENE-8883: - Commit 8233981e7f0e5bddc25860b02421a559dd38ccb3 in lucene-solr's branch refs/heads/branch_8x from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8233981 ] LUCENE-8883: addVersion.py now adds categories to CHANGES.txt (cherry picked from commit 742e6b7effe96977fa5372c0c4a8413528fd99cd) > CHANGES.txt: Auto add issue categories on new releases > -- > > Key: LUCENE-8883 > URL: https://issues.apache.org/jira/browse/LUCENE-8883 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-8883.patch, LUCENE-8883.patch, LUCENE-8883.patch > > > As I write this, looking at Solr's CHANGES.txt for 8.2 I see we have some > sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes". > There is no "Improvements" so no surprise here, the New Features category > has issues that ought to be listed as such. I think the order vary as well. > I propose that on new releases, the initial state of the next release in > CHANGES.txt have these sections. They can easily be removed at the upcoming > release if there are no such sections, or they could stay as empty. It seems > addVersion.py is the code that sets this up and it could be enhanced. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8883) CHANGES.txt: Auto add issue categories on new releases
[ https://issues.apache.org/jira/browse/LUCENE-8883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900938#comment-16900938 ] ASF subversion and git services commented on LUCENE-8883: - Commit 742e6b7effe96977fa5372c0c4a8413528fd99cd in lucene-solr's branch refs/heads/master from David Smiley [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=742e6b7 ] LUCENE-8883: addVersion.py now adds categories to CHANGES.txt > CHANGES.txt: Auto add issue categories on new releases > -- > > Key: LUCENE-8883 > URL: https://issues.apache.org/jira/browse/LUCENE-8883 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Reporter: David Smiley >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-8883.patch, LUCENE-8883.patch, LUCENE-8883.patch > > > As I write this, looking at Solr's CHANGES.txt for 8.2 I see we have some > sections: "Upgrade Notes", "New Features", "Bug Fixes", and "Other Changes". > There is no "Improvements" so no surprise here, the New Features category > has issues that ought to be listed as such. I think the order vary as well. > I propose that on new releases, the initial state of the next release in > CHANGES.txt have these sections. They can easily be removed at the upcoming > release if there are no such sections, or they could stay as empty. It seems > addVersion.py is the code that sets this up and it could be enhanced. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13677) All Metrics Gauges should be unregistered by the objects that registered them
[ https://issues.apache.org/jira/browse/SOLR-13677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900610#comment-16900610 ] ASF subversion and git services commented on SOLR-13677: Commit f983ede5fc7d14cb004d1e8674b709ffefd8b06e in lucene-solr's branch refs/heads/jira/SOLR-13677 from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f983ede ] SOLR-13677: Created an interface called GaugeRef instead of exposing the internal class GaugeWrapper > All Metrics Gauges should be unregistered by the objects that registered them > - > > Key: SOLR-13677 > URL: https://issues.apache.org/jira/browse/SOLR-13677 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: metrics >Reporter: Noble Paul >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The life cycle of Metrics producers are managed by the core (mostly). So, if > the lifecycle of the object is different from that of the core itself, these > objects will never be unregistered from the metrics registry. This will lead > to memory leaks -- This message was sent by Atlassian JIRA (v7.6.14#76016) - 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&focusedCommentId=16900392#comment-16900392
]
ASF subversion and git services commented on SOLR-13105:
Commit 85b9c6a62aac692176d685c8af72352d2e804514 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=85b9c6a ]
SOLR-13105: Add text to loading page 4
> 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.14#76016)
-
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&focusedCommentId=16900339#comment-16900339
]
ASF subversion and git services commented on SOLR-13105:
Commit 53724650be1254030a99038f9e403230ada73427 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=5372465 ]
SOLR-13105: Add text to loading page 3
> 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.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13678) ZkStateReader.removeCollectionPropsWatcher can deadlock with concurrent zkCallback thread on props watcher
[
https://issues.apache.org/jira/browse/SOLR-13678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900323#comment-16900323
]
ASF subversion and git services commented on SOLR-13678:
Commit b18041476ff0ad710c2ddf423cc4a9b0edddba4e in lucene-solr's branch
refs/heads/branch_8x from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b180414 ]
SOLR-13678: Harden CollectionPropsTest.testReadWriteCached to work around
removeCollectionPropsWatcher() deadlock bug
(cherry picked from commit a052fb5436840b45909446668c1137cb3f266c99)
> ZkStateReader.removeCollectionPropsWatcher can deadlock with concurrent
> zkCallback thread on props watcher
> --
>
> Key: SOLR-13678
> URL: https://issues.apache.org/jira/browse/SOLR-13678
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Major
> Attachments: collectionpropswatcher-deadlock-jstack.txt
>
>
> while investigating an (unrelated) test bug in CollectionPropsTest I
> discovered a deadlock situation that can occur when calling
> {{ZkStateReader.removeCollectionPropsWatcher()}} if a zkCallback thread tries
> to concurrently fire the watchers set on the collection props.
> {{ZkStateReader.removeCollectionPropsWatcher()}} is itself called when a
> {{CollectionPropsWatcher.onStateChanged()}} impl returns "true" -- meaning
> that IIUC any usage of {{CollectionPropsWatcher}} could potentially result in
> this type of deadlock situation.
> {noformat}
> "TEST-CollectionPropsTest.testReadWriteCached-seed#[D3C6921874D1CFEB]" #15
> prio=5 os_prio=0 cpu=567.78ms elapsed=682.12s tid=0x7
> fa5e8343800 nid=0x3f61 waiting for monitor entry [0x7fa62d222000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.solr.common.cloud.ZkStateReader.lambda$removeCollectionPropsWatcher$20(ZkStateReader.java:2001)
> - waiting to lock <0xe6207500> (a
> java.util.concurrent.ConcurrentHashMap)
> at
> org.apache.solr.common.cloud.ZkStateReader$$Lambda$617/0x0001006c1840.apply(Unknown
> Source)
> at
> java.util.concurrent.ConcurrentHashMap.compute(java.base@11.0.3/ConcurrentHashMap.java:1932)
> - locked <0xeb9156b8> (a
> java.util.concurrent.ConcurrentHashMap$Node)
> at
> org.apache.solr.common.cloud.ZkStateReader.removeCollectionPropsWatcher(ZkStateReader.java:1994)
> at
> org.apache.solr.cloud.CollectionPropsTest.testReadWriteCached(CollectionPropsTest.java:125)
> ...
> "zkCallback-88-thread-2" #213 prio=5 os_prio=0 cpu=14.06ms elapsed=672.65s
> tid=0x7fa6041bf000 nid=0x402f waiting for monitor ent
> ry [0x7fa5b8f39000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> java.util.concurrent.ConcurrentHashMap.compute(java.base@11.0.3/ConcurrentHashMap.java:1923)
> - waiting to lock <0xeb9156b8> (a
> java.util.concurrent.ConcurrentHashMap$Node)
> at
> org.apache.solr.common.cloud.ZkStateReader$PropsNotification.(ZkStateReader.java:2262)
> at
> org.apache.solr.common.cloud.ZkStateReader.notifyPropsWatchers(ZkStateReader.java:2243)
> at
> org.apache.solr.common.cloud.ZkStateReader$PropsWatcher.refreshAndWatch(ZkStateReader.java:1458)
> - locked <0xe6207500> (a
> java.util.concurrent.ConcurrentHashMap)
> at
> org.apache.solr.common.cloud.ZkStateReader$PropsWatcher.process(ZkStateReader.java:1440)
> at
> org.apache.solr.common.cloud.SolrZkClient$ProcessWatchWithExecutor.lambda$process$1(SolrZkClient.java:838)
> at
> org.apache.solr.common.cloud.SolrZkClient$ProcessWatchWithExecutor$$Lambda$253/0x0001004a4440.run(Unknown
> Source)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.3/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.3/FutureTask.java:264)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$140/0x000100308c40.run(Unknown
> Source)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.3/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.3/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.3/Thread.java:834)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.ap
[jira] [Commented] (SOLR-13678) ZkStateReader.removeCollectionPropsWatcher can deadlock with concurrent zkCallback thread on props watcher
[
https://issues.apache.org/jira/browse/SOLR-13678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16900310#comment-16900310
]
ASF subversion and git services commented on SOLR-13678:
Commit a052fb5436840b45909446668c1137cb3f266c99 in lucene-solr's branch
refs/heads/master from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a052fb5 ]
SOLR-13678: Harden CollectionPropsTest.testReadWriteCached to work around
removeCollectionPropsWatcher() deadlock bug
> ZkStateReader.removeCollectionPropsWatcher can deadlock with concurrent
> zkCallback thread on props watcher
> --
>
> Key: SOLR-13678
> URL: https://issues.apache.org/jira/browse/SOLR-13678
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Priority: Major
> Attachments: collectionpropswatcher-deadlock-jstack.txt
>
>
> while investigating an (unrelated) test bug in CollectionPropsTest I
> discovered a deadlock situation that can occur when calling
> {{ZkStateReader.removeCollectionPropsWatcher()}} if a zkCallback thread tries
> to concurrently fire the watchers set on the collection props.
> {{ZkStateReader.removeCollectionPropsWatcher()}} is itself called when a
> {{CollectionPropsWatcher.onStateChanged()}} impl returns "true" -- meaning
> that IIUC any usage of {{CollectionPropsWatcher}} could potentially result in
> this type of deadlock situation.
> {noformat}
> "TEST-CollectionPropsTest.testReadWriteCached-seed#[D3C6921874D1CFEB]" #15
> prio=5 os_prio=0 cpu=567.78ms elapsed=682.12s tid=0x7
> fa5e8343800 nid=0x3f61 waiting for monitor entry [0x7fa62d222000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.solr.common.cloud.ZkStateReader.lambda$removeCollectionPropsWatcher$20(ZkStateReader.java:2001)
> - waiting to lock <0xe6207500> (a
> java.util.concurrent.ConcurrentHashMap)
> at
> org.apache.solr.common.cloud.ZkStateReader$$Lambda$617/0x0001006c1840.apply(Unknown
> Source)
> at
> java.util.concurrent.ConcurrentHashMap.compute(java.base@11.0.3/ConcurrentHashMap.java:1932)
> - locked <0xeb9156b8> (a
> java.util.concurrent.ConcurrentHashMap$Node)
> at
> org.apache.solr.common.cloud.ZkStateReader.removeCollectionPropsWatcher(ZkStateReader.java:1994)
> at
> org.apache.solr.cloud.CollectionPropsTest.testReadWriteCached(CollectionPropsTest.java:125)
> ...
> "zkCallback-88-thread-2" #213 prio=5 os_prio=0 cpu=14.06ms elapsed=672.65s
> tid=0x7fa6041bf000 nid=0x402f waiting for monitor ent
> ry [0x7fa5b8f39000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> java.util.concurrent.ConcurrentHashMap.compute(java.base@11.0.3/ConcurrentHashMap.java:1923)
> - waiting to lock <0xeb9156b8> (a
> java.util.concurrent.ConcurrentHashMap$Node)
> at
> org.apache.solr.common.cloud.ZkStateReader$PropsNotification.(ZkStateReader.java:2262)
> at
> org.apache.solr.common.cloud.ZkStateReader.notifyPropsWatchers(ZkStateReader.java:2243)
> at
> org.apache.solr.common.cloud.ZkStateReader$PropsWatcher.refreshAndWatch(ZkStateReader.java:1458)
> - locked <0xe6207500> (a
> java.util.concurrent.ConcurrentHashMap)
> at
> org.apache.solr.common.cloud.ZkStateReader$PropsWatcher.process(ZkStateReader.java:1440)
> at
> org.apache.solr.common.cloud.SolrZkClient$ProcessWatchWithExecutor.lambda$process$1(SolrZkClient.java:838)
> at
> org.apache.solr.common.cloud.SolrZkClient$ProcessWatchWithExecutor$$Lambda$253/0x0001004a4440.run(Unknown
> Source)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(java.base@11.0.3/Executors.java:515)
> at
> java.util.concurrent.FutureTask.run(java.base@11.0.3/FutureTask.java:264)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
> at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor$$Lambda$140/0x000100308c40.run(Unknown
> Source)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@11.0.3/ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@11.0.3/ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(java.base@11.0.3/Thread.java:834)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
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&focusedCommentId=16900122#comment-16900122
]
ASF subversion and git services commented on SOLR-13105:
Commit 79b98a1dcb7b252f9d36316e9be6fe52883e1135 in lucene-solr's branch
refs/heads/SOLR-13105-visual from Joel Bernstein
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=79b98a1 ]
SOLR-13105: Add text to loading page 2
> 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.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11866) Support efficient subset matching in query elevation rules
[ https://issues.apache.org/jira/browse/SOLR-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899958#comment-16899958 ] ASF subversion and git services commented on SOLR-11866: Commit 445f4bf5c28b91ddf02f25d61f0b282995c99891 in lucene-solr's branch refs/heads/branch_8x from Bruno Roustant [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=445f4bf ] SOLR-11866: QueryElevationComponent match="subset" feature Closes #780 (cherry picked from commit d97912529d5ec4e86a8b6def4103bc6f4fbfd24b) > Support efficient subset matching in query elevation rules > -- > > Key: SOLR-11866 > URL: https://issues.apache.org/jira/browse/SOLR-11866 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 8.0 >Reporter: Bruno Roustant >Assignee: David Smiley >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > Leverages the SOLR-11865 refactoring by introducing a > SubsetMatchElevationProvider in QueryElevationComponent. This provider calls > a new util class TrieSubsetMatcher to efficiently match all query elevation > rules which subset is contained by the current query list of terms. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11866) Support efficient subset matching in query elevation rules
[ https://issues.apache.org/jira/browse/SOLR-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899934#comment-16899934 ] ASF subversion and git services commented on SOLR-11866: Commit d97912529d5ec4e86a8b6def4103bc6f4fbfd24b in lucene-solr's branch refs/heads/master from Bruno Roustant [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d979125 ] SOLR-11866: QueryElevationComponent match="subset" feature Closes #780 > Support efficient subset matching in query elevation rules > -- > > Key: SOLR-11866 > URL: https://issues.apache.org/jira/browse/SOLR-11866 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 8.0 >Reporter: Bruno Roustant >Assignee: David Smiley >Priority: Major > Time Spent: 2.5h > Remaining Estimate: 0h > > Leverages the SOLR-11865 refactoring by introducing a > SubsetMatchElevationProvider in QueryElevationComponent. This provider calls > a new util class TrieSubsetMatcher to efficiently match all query elevation > rules which subset is contained by the current query list of terms. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13650) Support for named global classloaders
[
https://issues.apache.org/jira/browse/SOLR-13650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899897#comment-16899897
]
ASF subversion and git services commented on SOLR-13650:
Commit 72a51df173ccfc09039fbc5dfae92dbd5c02ba4d in lucene-solr's branch
refs/heads/jira/SOLR-13650 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=72a51df ]
SOLR-13650: support cache loading
> Support for named global classloaders
> -
>
> Key: SOLR-13650
> URL: https://issues.apache.org/jira/browse/SOLR-13650
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Priority: Major
>
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "add-package": {
>"name": "my-package" ,
> "url" : "http://host:port/url/of/jar";,
> "sha512":""
> }
> }' http://localhost:8983/api/cluster
> {code}
> This means that Solr creates a globally accessible classloader with a name
> {{my-package}} which contains all the jars of that package.
> A component should be able to use the package by using the {{"package" :
> "my-package"}}.
> eg:
> {code:json}
> curl -X POST -H 'Content-type:application/json' --data-binary '
> {
> "create-searchcomponent": {
> "name": "my-searchcomponent" ,
> "class" : "my.path.to.ClassName",
> "package" : "my-package"
> }
> }' http://localhost:8983/api/c/mycollection/config
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml
[
https://issues.apache.org/jira/browse/SOLR-13679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899775#comment-16899775
]
ASF subversion and git services commented on SOLR-13679:
Commit 6fc042dd6d2e3660d9e91fc5000204aef5957e28 in lucene-solr's branch
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6fc042d ]
SOLR-13679: move changes entry to bug fix section
> Different default Style for [explain] doctransformer registered in
> solrconfig.xml
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch, SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
> class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this
> without adding it in solrconfig.xml but when used this way, default style
> used is {{text}}
> Default style should be same in both cases. This behavior is same to
> registering ResponseWriters in solrconfig, if content-type is not overridden
> then, default content-type will used
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml
[
https://issues.apache.org/jira/browse/SOLR-13679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899772#comment-16899772
]
ASF subversion and git services commented on SOLR-13679:
Commit b4e49206edbfb4e9dd580739f1271cea18135bc4 in lucene-solr's branch
refs/heads/branch_8x from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b4e4920 ]
SOLR-13679:Fix default style of [explain] registered in solrconfig.xml
> Different default Style for [explain] doctransformer registered in
> solrconfig.xml
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch, SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
> class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this
> without adding it in solrconfig.xml but when used this way, default style
> used is {{text}}
> Default style should be same in both cases. This behavior is same to
> registering ResponseWriters in solrconfig, if content-type is not overridden
> then, default content-type will used
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13679) Different default Style for [explain] doctransformer registered in solrconfig.xml
[
https://issues.apache.org/jira/browse/SOLR-13679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899763#comment-16899763
]
ASF subversion and git services commented on SOLR-13679:
Commit 84a62a5d873516686c8d04529f37175af2fb7be0 in lucene-solr's branch
refs/heads/master from Munendra S N
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=84a62a5 ]
SOLR-13679:Fix default style of [explain] registered in solrconfig.xml
> Different default Style for [explain] doctransformer registered in
> solrconfig.xml
> --
>
> Key: SOLR-13679
> URL: https://issues.apache.org/jira/browse/SOLR-13679
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Minor
> Attachments: SOLR-13679.patch, SOLR-13679.patch
>
>
> Adding explain docTransformer via solrconfig.xml
> {code:java}
> class="org.apache.solr.response.transform.ExplainAugmenterFactory" />
> {code}
> Here, no style is specified. So, default style is used which is {{nl}}.
> ExplainDocTransformer is part of defaultFactories. So, user can use this
> without adding it in solrconfig.xml but when used this way, default style
> used is {{text}}
> Default style should be same in both cases. This behavior is same to
> registering ResponseWriters in solrconfig, if content-type is not overridden
> then, default content-type will used
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13676) Reduce log verbosity in TestDistributedGrouping using ignoreException
[
https://issues.apache.org/jira/browse/SOLR-13676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899755#comment-16899755
]
ASF subversion and git services commented on SOLR-13676:
Commit 696e752be62f3e00b4b59675b544d0245899f782 in lucene-solr's branch
refs/heads/branch_8x from Diego
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=696e752 ]
SOLR-13676: Reduce log verbosity in TestDistributedGrouping (#819)
* SOLR-13676: Reduce log verbosity in TestDistributedGrouping using
ignoreException
* Code review
* Remove Assert
> Reduce log verbosity in TestDistributedGrouping using ignoreException
> -
>
> Key: SOLR-13676
> URL: https://issues.apache.org/jira/browse/SOLR-13676
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Diego Ceccarelli
>Assignee: Munendra S N
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> SOLR-13404 added a test that expects Solr to fail if grouping is called with
> {{group.offset < 0}}. When the test runs it succeeds but the whole stack
> trace is printed out in the logs. This small patch avoid the stack trace by
> using {{ignoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13676) Reduce log verbosity in TestDistributedGrouping using ignoreException
[
https://issues.apache.org/jira/browse/SOLR-13676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899754#comment-16899754
]
ASF subversion and git services commented on SOLR-13676:
Commit 696e752be62f3e00b4b59675b544d0245899f782 in lucene-solr's branch
refs/heads/branch_8x from Diego
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=696e752 ]
SOLR-13676: Reduce log verbosity in TestDistributedGrouping (#819)
* SOLR-13676: Reduce log verbosity in TestDistributedGrouping using
ignoreException
* Code review
* Remove Assert
> Reduce log verbosity in TestDistributedGrouping using ignoreException
> -
>
> Key: SOLR-13676
> URL: https://issues.apache.org/jira/browse/SOLR-13676
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Diego Ceccarelli
>Assignee: Munendra S N
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> SOLR-13404 added a test that expects Solr to fail if grouping is called with
> {{group.offset < 0}}. When the test runs it succeeds but the whole stack
> trace is printed out in the logs. This small patch avoid the stack trace by
> using {{ignoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13676) Reduce log verbosity in TestDistributedGrouping using ignoreException
[
https://issues.apache.org/jira/browse/SOLR-13676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899752#comment-16899752
]
ASF subversion and git services commented on SOLR-13676:
Commit 751e64651cd612a78842bf652bf9a3b77322fc40 in lucene-solr's branch
refs/heads/master from Diego
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=751e646 ]
SOLR-13676: Reduce log verbosity in TestDistributedGrouping (#819)
* SOLR-13676: Reduce log verbosity in TestDistributedGrouping using
ignoreException
* Code review
* Remove Assert
> Reduce log verbosity in TestDistributedGrouping using ignoreException
> -
>
> Key: SOLR-13676
> URL: https://issues.apache.org/jira/browse/SOLR-13676
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Diego Ceccarelli
>Assignee: Munendra S N
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> SOLR-13404 added a test that expects Solr to fail if grouping is called with
> {{group.offset < 0}}. When the test runs it succeeds but the whole stack
> trace is printed out in the logs. This small patch avoid the stack trace by
> using {{ignoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13676) Reduce log verbosity in TestDistributedGrouping using ignoreException
[
https://issues.apache.org/jira/browse/SOLR-13676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16899751#comment-16899751
]
ASF subversion and git services commented on SOLR-13676:
Commit 751e64651cd612a78842bf652bf9a3b77322fc40 in lucene-solr's branch
refs/heads/master from Diego
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=751e646 ]
SOLR-13676: Reduce log verbosity in TestDistributedGrouping (#819)
* SOLR-13676: Reduce log verbosity in TestDistributedGrouping using
ignoreException
* Code review
* Remove Assert
> Reduce log verbosity in TestDistributedGrouping using ignoreException
> -
>
> Key: SOLR-13676
> URL: https://issues.apache.org/jira/browse/SOLR-13676
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Reporter: Diego Ceccarelli
>Assignee: Munendra S N
>Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> SOLR-13404 added a test that expects Solr to fail if grouping is called with
> {{group.offset < 0}}. When the test runs it succeeds but the whole stack
> trace is printed out in the logs. This small patch avoid the stack trace by
> using {{ignoreException}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
