[JENKINS] Lucene-Solr-NightlyTests-master - Build # 1848 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-master/1848/
1 tests failed.
FAILED:
org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest.testSimple
Error Message:
Waiting for collection testSimple2 Timeout waiting to see state for
collection=testSimple2
:DocCollection(testSimple2//collections/testSimple2/state.json/28)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{
"range":"8000-", "state":"active", "replicas":{
"core_node3":{
"dataDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node3/data/",
"base_url":"http://127.0.0.1:41665/solr;,
"node_name":"127.0.0.1:41665_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node3/data/tlog",
"core":"testSimple2_shard1_replica_n1",
"shared_storage":"true", "state":"active",
"leader":"true"}, "core_node5":{
"dataDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node5/data/",
"base_url":"http://127.0.0.1:37674/solr;,
"node_name":"127.0.0.1:37674_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node5/data/tlog",
"core":"testSimple2_shard1_replica_n2",
"shared_storage":"true", "state":"down"}}}, "shard2":{
"range":"0-7fff", "state":"active", "replicas":{
"core_node7":{
"dataDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node7/data/",
"base_url":"http://127.0.0.1:41665/solr;,
"node_name":"127.0.0.1:41665_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node7/data/tlog",
"core":"testSimple2_shard2_replica_n4",
"shared_storage":"true", "state":"active",
"leader":"true"}, "core_node8":{
"dataDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node8/data/",
"base_url":"http://127.0.0.1:37674/solr;,
"node_name":"127.0.0.1:37674_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node8/data/tlog",
"core":"testSimple2_shard2_replica_n6",
"shared_storage":"true", "state":"down",
"router":{"name":"compositeId"}, "maxShardsPerNode":"2",
"autoAddReplicas":"true", "nrtReplicas":"2", "tlogReplicas":"0"} Live
Nodes: [127.0.0.1:36647_solr, 127.0.0.1:41665_solr] Last available state:
DocCollection(testSimple2//collections/testSimple2/state.json/28)={
"pullReplicas":"0", "replicationFactor":"2", "shards":{ "shard1":{
"range":"8000-", "state":"active", "replicas":{
"core_node3":{
"dataDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node3/data/",
"base_url":"http://127.0.0.1:41665/solr;,
"node_name":"127.0.0.1:41665_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node3/data/tlog",
"core":"testSimple2_shard1_replica_n1",
"shared_storage":"true", "state":"active",
"leader":"true"}, "core_node5":{
"dataDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node5/data/",
"base_url":"http://127.0.0.1:37674/solr;,
"node_name":"127.0.0.1:37674_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node5/data/tlog",
"core":"testSimple2_shard1_replica_n2",
"shared_storage":"true", "state":"down"}}}, "shard2":{
"range":"0-7fff", "state":"active", "replicas":{
"core_node7":{
"dataDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node7/data/",
"base_url":"http://127.0.0.1:41665/solr;,
"node_name":"127.0.0.1:41665_solr", "type":"NRT",
"force_set_state":"false",
"ulogDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node7/data/tlog",
"core":"testSimple2_shard2_replica_n4",
"shared_storage":"true", "state":"active",
"leader":"true"}, "core_node8":{
"dataDir":"hdfs://localhost:37436/solr_hdfs_home/testSimple2/core_node8/data/",
"base_url":"http://127.0.0.1:37674/solr;,
"node_name":"127.0.0.1:37674_solr", "type":"NRT",
"force_set_state":"false",
[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=16840570#comment-16840570 ] Mark Miller commented on SOLR-13452: bq. IMHO, the build plugin should also contain the JFlex task, currently its applied on top-level. Ah, I misread this, I thought you meant there should be a jflex task top level. I tried to put this in buildSrc only and had some issues access the right classpath for the ant task def, but I agree. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11558) It would be nice if the Graph section of the Cloud tab in the Admin UI could give some more information about the replicas of a collection
[ https://issues.apache.org/jira/browse/SOLR-11558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840619#comment-16840619 ] Erick Erickson commented on SOLR-11558: --- [~tomasflobbe] I'll raise another Jira with the details so I can close this one today. > It would be nice if the Graph section of the Cloud tab in the Admin UI could > give some more information about the replicas of a collection > -- > > Key: SOLR-11558 > URL: https://issues.apache.org/jira/browse/SOLR-11558 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Tomás Fernández Löbbe >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-11558.patch > > > Right now it lists the nodes where they are hosted, the state and if they are > or not leader. I usually find the need to see more, like the replica and core > names and the replica type, and I find myself moving between this view and > the “tree” view. > I thought about two options: > # A mouse over action that lists the additional information (after some time > of holding the mouse pointer on top of the replica) > # Modify the click action to display this information (right now the click > sends you to the admin UI of that particular replica) > The same could be done to display some extra information of the shard (like > active/inactive, routing range) and the collection (autoAddReplicas, > maxShardsPerNode, configset, etc) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8799) Add Force Commit Method to RandomIndexWriter
[ https://issues.apache.org/jira/browse/LUCENE-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840620#comment-16840620 ] Adrien Grand commented on LUCENE-8799: -- [~atris] I don't have a checkout of the code locally so apologies if I'm missing something, but it looks like calling RandomIndexWriter.commit(false) today would call w.commit(), just like the new method you are proposing? > Add Force Commit Method to RandomIndexWriter > > > Key: LUCENE-8799 > URL: https://issues.apache.org/jira/browse/LUCENE-8799 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Atri Sharma >Priority: Minor > Attachments: LUCENE-8799.patch > > > A test convenience would be to add a force commit method in > RandomIndexWriter. This will allow writing tests where segment sizes can be > accurately controlled. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11558) It would be nice if the Graph section of the Cloud tab in the Admin UI could give some more information about the replicas of a collection
[ https://issues.apache.org/jira/browse/SOLR-11558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840645#comment-16840645 ] ASF subversion and git services commented on SOLR-11558: Commit 9ff5eb30af846f2396230606bcffe2862ca7f528 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9ff5eb3 ] SOLR-11558: It would be nice if the Graph section of the Cloud tab in the Admin UI could give some more information about the replicas of a collection > It would be nice if the Graph section of the Cloud tab in the Admin UI could > give some more information about the replicas of a collection > -- > > Key: SOLR-11558 > URL: https://issues.apache.org/jira/browse/SOLR-11558 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Tomás Fernández Löbbe >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-11558.patch > > > Right now it lists the nodes where they are hosted, the state and if they are > or not leader. I usually find the need to see more, like the replica and core > names and the replica type, and I find myself moving between this view and > the “tree” view. > I thought about two options: > # A mouse over action that lists the additional information (after some time > of holding the mouse pointer on top of the replica) > # Modify the click action to display this information (right now the click > sends you to the admin UI of that particular replica) > The same could be done to display some extra information of the shard (like > active/inactive, routing range) and the collection (autoAddReplicas, > maxShardsPerNode, configset, etc) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-11558) It would be nice if the Graph section of the Cloud tab in the Admin UI could give some more information about the replicas of a collection
[ https://issues.apache.org/jira/browse/SOLR-11558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840619#comment-16840619 ] Erick Erickson edited comment on SOLR-11558 at 5/15/19 6:30 PM: [~tomasflobbe] Turns out I can't reproduce unless I specify something like replicationFactor as well as PULL and TLOG replicas. I was probably seeing things at the end of a long plane ride. was (Author: erickerickson): [~tomasflobbe] I'll raise another Jira with the details so I can close this one today. > It would be nice if the Graph section of the Cloud tab in the Admin UI could > give some more information about the replicas of a collection > -- > > Key: SOLR-11558 > URL: https://issues.apache.org/jira/browse/SOLR-11558 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Tomás Fernández Löbbe >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-11558.patch > > > Right now it lists the nodes where they are hosted, the state and if they are > or not leader. I usually find the need to see more, like the replica and core > names and the replica type, and I find myself moving between this view and > the “tree” view. > I thought about two options: > # A mouse over action that lists the additional information (after some time > of holding the mouse pointer on top of the replica) > # Modify the click action to display this information (right now the click > sends you to the admin UI of that particular replica) > The same could be done to display some extra information of the shard (like > active/inactive, routing range) and the collection (autoAddReplicas, > maxShardsPerNode, configset, etc) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840508#comment-16840508 ] Martin Grigorov commented on SOLR-13452: OK. I just wanted to mention it since you just started on this migration (Ant -> Gradle). > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840507#comment-16840507 ] ASF subversion and git services commented on SOLR-13452: Commit 9471e3edf7eaafb94d91207c4e71e33b3ded2fcc in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9471e3e ] SOLR-13452: Do some general cleanup and pull test and implementationTran config into their own files as well to simplify the main build.gradle. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840529#comment-16840529 ] Tomoko Uchida commented on SOLR-13452: -- bq. I think Groovy seems more widely known and used with Gradle currently and one of the primary motivations here is to use something that most devs will be familiar with and that has great support and tooling. I agree with that, thanks. (I imagine most ordinary devs like me are accustomed to the grvoovy DSL, though don't know well groovy itself.) > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840530#comment-16840530 ] ASF subversion and git services commented on SOLR-13452: Commit 0cf666e95b9c8e8565acd67b541d3a0c8fa27157 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0cf666e ] SOLR-13452: A bit more cleanup and start adding license headers to new gradle files. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13350) Explore collector managers for multi-threaded search
[ https://issues.apache.org/jira/browse/SOLR-13350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840549#comment-16840549 ] Yonik Seeley commented on SOLR-13350: - In general, it seems like an executor for parallel searches would be more useful at the CoreContainer level. If the executor is per-searcher, then picking a high enough pool size for good concurrency for a single core means that one would get way to many threads if one has tons of cores per node (not that unusual) We should also audit all Weight classes in Solr for thread safety (if it hasn't been done yet.) . Relying on existing tests to catch stuff like that won't work that well for catching race conditions. > Explore collector managers for multi-threaded search > > > Key: SOLR-13350 > URL: https://issues.apache.org/jira/browse/SOLR-13350 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Assignee: Ishan Chattopadhyaya >Priority: Major > Attachments: SOLR-13350.patch, SOLR-13350.patch, SOLR-13350.patch > > Time Spent: 10m > Remaining Estimate: 0h > > AFAICT, SolrIndexSearcher can be used only to search all the segments of an > index in series. However, using CollectorManagers, segments can be searched > concurrently and result in reduced latency. Opening this issue to explore the > effectiveness of using CollectorManagers in SolrIndexSearcher from latency > and throughput perspective. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840449#comment-16840449 ] ASF subversion and git services commented on SOLR-13452: Commit 4225da138ac3fd2d51f88b947f9387cb6c5deee2 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4225da1 ] SOLR-13452: Pull eclipse config into it's own file and exclude benchmark/work and benchmark/temp as the file sizes and counts in those folders can make eclipse unhappy. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840514#comment-16840514 ] ASF subversion and git services commented on SOLR-13452: Commit 7b2acf61e79b7096dbe7ad4200e769ebca0a0d8f in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7b2acf6 ] SOLR-13452: Organize main build.gradle a bit. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840538#comment-16840538 ] ASF subversion and git services commented on SOLR-13452: Commit 63a057f84835fb0f13e6c6af7985816eb0d66149 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=63a057f ] SOLR-13452: Fix Git Working copy check; only detect unversioned files; TODO: on checking fails on all modifications > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347
ErickErickson commented on issue #665: Fixes SOLR-11841, SOLR-13331, SOLR-13347 URL: https://github.com/apache/lucene-solr/pull/665#issuecomment-492758246 There are two things that might help with the arbitrary change issue: 1> On the reviewing side, In InteliJ, I can choose an option “ignore all whitespace”, I’m sure other tools have similar. Doesn’t help with final and the like of course. 2> Again in IntelliJ and (presumably) other tools I can set the autoformat to only reformat changed lines rather than entire files. FWIW, Erick > On May 15, 2019, at 6:49 AM, David Smiley wrote: > > It'd help to review your changes if you made fewer arbitrary changes, like adding 'final' and changing indentation of javadocs that were fine as they were. > Also, it'd help to summarize why 3 different issues are being fixed in one PR. Might be just fine but please add info/context to make reviewer's job either or you may not get a review at all. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread. > This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13439) Make collection properties easier and safer to use in code
[
https://issues.apache.org/jira/browse/SOLR-13439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840611#comment-16840611
]
Gus Heck commented on SOLR-13439:
-
{quote}Exactly, which is why the option of not setting a watch exists for cases
that only need infrequent access.
{quote}
If that option is truly important, we can have 2 methods, one that does cause a
watch/cache and one that hits zookeeper every time, getCollectionProperties()
and getCachedCollectionProperties() perhaps?
{quote}Not on only those cases. There are two more leak scenarios that I’d like
to consider:
# Even if the PropsWatcher expires and it’s removed from the cache, ZooKeeper
server will still maintain the watch referenced to this zkClient, that means we
just keep accumulating them for every call to getCollectionProperties. If you
do this to many collections and collection properties changes are infrequent,
this may become a problem. I believe the PropsWatcher object won’t be garbage
collected, since it includes the callback.{quote}
ZkStateReader lives at the CoreContainer level. so we have one per node, and
thus one instance of the zk client. Looking into the zookeeper code, what I
think I see is a map of path (String) to HashSet, but the watchers
added to that set are instances of ServerCnxn.java (which implements watcher)
which appears to also be the object representing the connection to the client,
of which (I think) there will only be one per client. So the max load on the
zookeeper server side for a given path is set by the number of Solr nodes
observing that path. So the absolute worst case for the server in this code is
{{collections X nodes}} if every collection has a shard on every node, the
properties never change and every collection has it's properties queried. The
worst case hasn't changed, though it does become more likely with the direction
I'm heading.
According to ZOOKEEPER-1177 a watch is about 100 bytes... so a 1000 collections
on 100 nodes (100k watches) could generate up to 10Mb of watches on the server.
According to that issue, performance of the "old" (which is what 3.4.14 would
be since that issue is fixed for 3.6) is:
{code:java}
OLD
[junit] 9736ms to add
[junit] size:1000
[junit] 0ms to size
[junit] 5615ms to dumpwatches true
[junit] 3035ms to dumpwatches false
[junit] 5530ms to trigger{code}
those numbers are for 10M watches so those operations on our 100K example is
likely to run in the tens of ms. (the foregoing assuming I understood the code
and the issue correctly, and a linear relationship vs number of watches).
In zookeeper 3.5 we'll also have the opportunity to cull out watches on with
ZOOKEEPER-442
So server side in zk, it looks like we should be able to handle some fairly
beefy use cases, what's the max nodes times collections you think we need to
support? Do you have large test clusters on which to validate these effects? (I
do not unfortunately).
As for GC I did think about that... references to a PropsWatcher are held in 2
places:
# The ConditionalExpiringCache as a value
# The closure created when the anonymous implementation of SolrZkWatcher is
created
Once the watch fires, the anonymous wrapper should not be referenced by zk code
and become held by a lambda submitted to the executor, which in turn is
discarded once the call to process() finishes. Once the watch has fired and the
cache has expired there are no references held and it becomes GC eligible.
GC is prevented however if the result of process() (called by the lambda) is to
call refreshAndWatch() (in the event that a CollectionPropsWatch still exists)
since that will put it back in the ConditionalExpiringCache with a renewed
timestamp and re-register the watch for zk.
{quote}2 Even if you keep calling getCollectionProperties on the same
collection, but after expiration, you keep adding new watches, for the same
path. That not only means leaks of watches in ZooKeeper server and PropsWatcher
objects in Solr, but also that, if at some point later in time a collection
property changes all those watches are going to fire at the same time. Even
more, if at the time of the fire, the collection is in the cache (because of a
recent call to getCollectionProperties), all those watches for the same path,
will re-fetch the collections properties file and then re-set. This arguably
can happen today, if someone uses watchers in the same way (add/remove watches
rapidly), but the idea of the watch is to be longer lived (i.e. the life of the
core), while with the patch it would happen with components that just call
getCollectionProperties with some frequency (i.e. per request, in cases with
low request rate)
{quote}
Some further research shows that we may have a subtle preexisting problem
there. Zookeeper keeps a set of watches so adding the same watch object to it
repeatedly is not a big deal at
[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=16840512#comment-16840512 ] ASF subversion and git services commented on SOLR-13452: Commit 9cc0a9bc69e547fe464dffe20b97703bcad63b75 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9cc0a9b ] SOLR-13452: Move more test config from main build.gradle to test config file. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob commented on a change in pull request #666: SOLR-13437: fork noggit code into Solr
madrob commented on a change in pull request #666: SOLR-13437: fork noggit code into Solr URL: https://github.com/apache/lucene-solr/pull/666#discussion_r284325579 ## File path: solr/solrj/src/java/org/apache/solr/common/json/ObjectBuilder.java ## @@ -0,0 +1,166 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more Review comment: The files that had a copyright claim in the header need to continue to have the copyright attribution, namely ` * Copyright 2006- Yonik Seeley` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-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=16840540#comment-16840540 ] Uwe Schindler commented on SOLR-13452: -- [~markrmil...@gmail.com]: I fixed the working copy check (there was a copy-paste error). What's the exact issue with forbidden-apis? The lucene BuildPlugin is not yet applied on all subprojects, with comment "forbidden" is not working. I temporary enabled it, it just failed because the BuildPlugin itsself uses java.io.File - hihi. IMHO, the build plugin should also contain the JFlex task, currently its applied on 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11558) It would be nice if the Graph section of the Cloud tab in the Admin UI could give some more information about the replicas of a collection
[ https://issues.apache.org/jira/browse/SOLR-11558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840605#comment-16840605 ] Tomás Fernández Löbbe commented on SOLR-11558: -- No, that shouldn't be happening. Did you use the UI or an API call to create the collection? > It would be nice if the Graph section of the Cloud tab in the Admin UI could > give some more information about the replicas of a collection > -- > > Key: SOLR-11558 > URL: https://issues.apache.org/jira/browse/SOLR-11558 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Tomás Fernández Löbbe >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-11558.patch > > > Right now it lists the nodes where they are hosted, the state and if they are > or not leader. I usually find the need to see more, like the replica and core > names and the replica type, and I find myself moving between this view and > the “tree” view. > I thought about two options: > # A mouse over action that lists the additional information (after some time > of holding the mouse pointer on top of the replica) > # Modify the click action to display this information (right now the click > sends you to the admin UI of that particular replica) > The same could be done to display some extra information of the shard (like > active/inactive, routing range) and the collection (autoAddReplicas, > maxShardsPerNode, configset, etc) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13407) Reject updates sent to non-routed multi collection aliases
[ https://issues.apache.org/jira/browse/SOLR-13407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840437#comment-16840437 ] David Smiley commented on SOLR-13407: - FYI possibly related bug: http://lucene.472066.n3.nabble.com/Solr-8-1-issue-with-collection-aliases-td4435463.html > Reject updates sent to non-routed multi collection aliases > -- > > Key: SOLR-13407 > URL: https://issues.apache.org/jira/browse/SOLR-13407 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Andrzej Bialecki >Assignee: Andrzej Bialecki >Priority: Major > Fix For: 8.1, master (9.0) > > Attachments: SOLR-13407.patch > > > Spin-off from SOLR-13262. > Currently Solr uses a convention that updates sent to multi-collection > aliases are applied only to the first collection on the list, which is > nonintuitive and may hide bugs or accidental configuration changes made > either in Solr or in client applications. > This issue proposes to reject all such updates with an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840459#comment-16840459 ] Mark Miller commented on SOLR-13452: I think Goovy seems more widely known and used with Gradle currently and one of the primary motivations here is to use something that most devs will be familiar with and that has great support and tooling. If that changes, we would/cloud consider moving in the future I would imagine. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840505#comment-16840505 ] Uwe Schindler commented on SOLR-13452: -- I'd like to stay with Groovy, too. The main reason why most custom tasks in our Ant build were written in Groovy was also done with "Gradle" in mind. [~mgrigorov]: most of the custom code added here (tasks like source code checker, regenerate of unicode data, and - not yet included here - in Lucene 8.x the MR-JAR creation with classfile patching) was copy-pasted from Ants build and just wrapped with a "gradle task" wrapper. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-master - Build # 361 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-master/361/ 1 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test Error Message: Timed out waiting for replica core_node12 (1557935077912) to replicate from leader core_node4 (0) Stack Trace: java.lang.AssertionError: Timed out waiting for replica core_node12 (1557935077912) to replicate from leader core_node4 (0) at __randomizedtesting.SeedInfo.seed([4059265D6B627B1A:C80D1987C59E16E2]:0) at org.junit.Assert.fail(Assert.java:88) at org.apache.solr.cloud.AbstractFullDistribZkTestBase.waitForReplicationFromReplicas(AbstractFullDistribZkTestBase.java:2271) at org.apache.solr.cloud.ChaosMonkeySafeLeaderWithPullReplicasTest.test(ChaosMonkeySafeLeaderWithPullReplicasTest.java:211) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:1082) at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:1054) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[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=16840562#comment-16840562 ] Mark Miller commented on SOLR-13452: bq. What's the exact issue with forbidden-apis? It fails because it was checking hadoop classes or something and I see in ant there are excludes for that, but we don't have them here yet. bq. IMHO, the build plugin should also contain the JFlex task, currently its applied on top-level. Yeah, I think that makes sense, JFlex is not fully done yet, maybe 70%. bq. While playing around, it was hard to me to find all custom defined tasks, as none of them has a description. I'll address that. In general, I just tried to start pulling some config out of the main build.gradle as I find it becomes hard to follow easily. I don't know if that is good practice or what we should do or what, but I think for me it made things simpler. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-11558) It would be nice if the Graph section of the Cloud tab in the Admin UI could give some more information about the replicas of a collection
[ https://issues.apache.org/jira/browse/SOLR-11558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-11558. --- Resolution: Fixed Fix Version/s: 8.2 master (9.0) > It would be nice if the Graph section of the Cloud tab in the Admin UI could > give some more information about the replicas of a collection > -- > > Key: SOLR-11558 > URL: https://issues.apache.org/jira/browse/SOLR-11558 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Tomás Fernández Löbbe >Assignee: Erick Erickson >Priority: Minor > Fix For: master (9.0), 8.2 > > Attachments: SOLR-11558.patch > > > Right now it lists the nodes where they are hosted, the state and if they are > or not leader. I usually find the need to see more, like the replica and core > names and the replica type, and I find myself moving between this view and > the “tree” view. > I thought about two options: > # A mouse over action that lists the additional information (after some time > of holding the mouse pointer on top of the replica) > # Modify the click action to display this information (right now the click > sends you to the admin UI of that particular replica) > The same could be done to display some extra information of the shard (like > active/inactive, routing range) and the collection (autoAddReplicas, > maxShardsPerNode, configset, etc) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11558) It would be nice if the Graph section of the Cloud tab in the Admin UI could give some more information about the replicas of a collection
[ https://issues.apache.org/jira/browse/SOLR-11558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840656#comment-16840656 ] ASF subversion and git services commented on SOLR-11558: Commit fef5d097d5cedbee43eaa8d7f98208be32ed9cbf in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fef5d09 ] SOLR-11558: It would be nice if the Graph section of the Cloud tab in the Admin UI could give some more information about the replicas of a collection (cherry picked from commit 9ff5eb30af846f2396230606bcffe2862ca7f528) > It would be nice if the Graph section of the Cloud tab in the Admin UI could > give some more information about the replicas of a collection > -- > > Key: SOLR-11558 > URL: https://issues.apache.org/jira/browse/SOLR-11558 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Tomás Fernández Löbbe >Assignee: Erick Erickson >Priority: Minor > Attachments: SOLR-11558.patch > > > Right now it lists the nodes where they are hosted, the state and if they are > or not leader. I usually find the need to see more, like the replica and core > names and the replica type, and I find myself moving between this view and > the “tree” view. > I thought about two options: > # A mouse over action that lists the additional information (after some time > of holding the mouse pointer on top of the replica) > # Modify the click action to display this information (right now the click > sends you to the admin UI of that particular replica) > The same could be done to display some extra information of the shard (like > active/inactive, routing range) and the collection (autoAddReplicas, > maxShardsPerNode, configset, etc) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840594#comment-16840594 ] ASF subversion and git services commented on SOLR-13452: Commit 51fb0655791b3a5083bdbc52494ae706c71a5ba0 in lucene-solr's branch refs/heads/jira/SOLR-13452_gradle from Mark Robert Miller [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=51fb065 ] SOLR-13452: Start adding group and description to 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-7.7 - Build # 12 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-7.7/12/ No tests ran. Build Log: [...truncated 23463 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2465 links (2015 relative) to 3226 anchors in 246 files [echo] Validated Links & Anchors via: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr.tgz.unpacked [untar] Expanding: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/package/solr-7.7.2.tgz into /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-7.7/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings ::
[jira] [Commented] (SOLR-13439) Make collection properties easier and safer to use in code
[ https://issues.apache.org/jira/browse/SOLR-13439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840616#comment-16840616 ] Erick Erickson commented on SOLR-13439: --- That code has been extensively re-worked, [~sarkaramr...@gmail.com] would have a much better idea of its current state. > Make collection properties easier and safer to use in code > -- > > Key: SOLR-13439 > URL: https://issues.apache.org/jira/browse/SOLR-13439 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (9.0) >Reporter: Gus Heck >Assignee: Gus Heck >Priority: Major > Attachments: SOLR-13439.patch, SOLR-13439.patch > > > (breaking this out from SOLR-13420, please read there for further background) > Before this patch the api is quite confusing (IMHO): > # any code that wanted to know what the properties for a collection are > could call zkStateReader.getCollectionProperties(collection) but this was a > dangerous and trappy API because that was a query to zookeeper every time. If > a naive user auto-completed that in their IDE without investigating, heavy > use of zookeeper would ensue. > # To "do it right" for any code that might get called on a per-doc or per > request basis one had to cause caching by registering a watcher. At which > point the getCollectionProperties(collection) magically becomes safe to use, > but the watcher pattern probably looks famillar induces a user who hasn't > read the solr code closely to create their own cache and update it when their > watcher is notified. If the caching side effect of watches isn't understood > this will lead to many in-memory copies of collection properties maintained > in user code. > # This also creates a task to be scheduled on a thread (PropsNotification) > and induces an extra thread-scheduling lag before the changes can be observed > by user code. > # The code that cares about collection properties needs to have a lifecycle > tied to either a collection or something other object with an even more > ephemeral life cycle such as an URP. The user now also has to remember to > ensure the watch is unregistered, or there is a leak. > After this patch > # Calls to getCollectionProperties(collection) are always safe to use in any > code anywhere. Caching and cleanup are automatic. > # Code that really actually wants to know if a collection property changes > so it can wake up and do something (autoscaling?) still has the option of > registering a watcher that will asynchronously send them a notification. > # Updates can be observed sooner via getCollectionProperties with no need to > wait for a thread to run. (vs a cache held in user code) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (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=16840459#comment-16840459 ] Mark Miller edited comment on SOLR-13452 at 5/15/19 2:24 PM: - I think Groovy seems more widely known and used with Gradle currently and one of the primary motivations here is to use something that most devs will be familiar with and that has great support and tooling. If that changes, we would/could consider moving in the future I would imagine. was (Author: markrmil...@gmail.com): I think Goovy seems more widely known and used with Gradle currently and one of the primary motivations here is to use something that most devs will be familiar with and that has great support and tooling. If that changes, we would/cloud consider moving in the future I would imagine. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr 8.1 issue with collection aliases
Thanks Jörn for reporting this. Sounds like some backward comparability
break with aliases. Can you please open a JIRA? I'll take a look at
reproducing it soon.
On Wed, 15 May, 2019, 7:18 PM Mikhail Khludnev, wrote:
> It seems creating alias in Solr Admin UI is broken. It's a minor issue for
> 8.1.0
> I've alias via REST call
> http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
> successfully.
> Jörn, thanks for reporting.
>
> On Tue, May 14, 2019 at 11:03 PM Jörn Franke wrote:
>
>> Hi,
>>
>> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with
>> collection aliases, but I am not 100% sure it is due to the upgrade.
>>
>> Situation:
>> I have a collection called c_testcollection.
>> I have an alias called testcollection.
>> Alias "testcollection" points to "c_testcollection".
>> On Solr 8.0 no issue
>>
>> After upgrade to Solr 8.1:
>> When I do a query on c_testcollection then there is no issue:
>> http://localhost:8983/solr/c_testcollection/select?q=test
>> When I do a query on testcollection then I receive the stacktrace below
>> http://localhost:8983/solr/testcollection/select?q=test
>>
>> Additionally I observe a strange behavior in the admin ui. When I try to
>> create an alias (e.g. new) for a new collection (e.g. c_new) then it
>> creates two aliases:
>> new => c_new
>> c_new => c_new
>> if i then do a query on the alias new it works without issues. If I remove
>> the alias from c_new to c_new then I get the same error. Is this desired
>> behaviour?
>> It is rather annoying to have unnecessary aliases, because I need to
>> filter
>> them out in my application when retrieving all aliases.
>> Is there a related issue.
>>
>> Here the stacktrace:
>> {
>> "error":{
>> "trace":"java.lang.NullPointerException\n\tat
>>
>> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>>
>> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>>
>> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
>>
>> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
>> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
>>
>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>>
>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>>
>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>>
>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\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:1588)\n\tat
>>
>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>>
>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>>
>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>>
>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>>
>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>>
>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>>
>> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>>
>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>>
>> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\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:502)\n\tat
>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>>
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
[GitHub] [lucene-solr] madrob commented on a change in pull request #666: SOLR-13437: fork noggit code into Solr
madrob commented on a change in pull request #666: SOLR-13437: fork noggit code into Solr URL: https://github.com/apache/lucene-solr/pull/666#discussion_r283607834 ## File path: solr/solrj/src/java/org/apache/solr/common/json/ObjectBuilder.java ## @@ -0,0 +1,166 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more Review comment: This file was originally with a header "Copyright 2006- Yonik Seeley" I don't think we can remove that, and might have to also carry forward a line in a NOTICE.txt to meet the ASLv2 requirements. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-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=16840546#comment-16840546 ] Uwe Schindler commented on SOLR-13452: -- One small thing: While playing around, it was hard to me to find all custom defined tasks, as none of them has a description. "gradle tasks" only shows those which have a description. So we should add a short statement for stuff like "regenerate". > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8799) Add Force Commit Method to RandomIndexWriter
[ https://issues.apache.org/jira/browse/LUCENE-8799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840674#comment-16840674 ] Atri Sharma commented on LUCENE-8799: - [~jpountz] Hmm, good point. I think the elaborate steps RandomIndexWriter takes to flush concurrently is what causes a bit of confusion. Would it make sense to add docs around the method, calling out what exactly happens when you pass in true/false, or would it be an overkill? > Add Force Commit Method to RandomIndexWriter > > > Key: LUCENE-8799 > URL: https://issues.apache.org/jira/browse/LUCENE-8799 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Atri Sharma >Priority: Minor > Attachments: LUCENE-8799.patch > > > A test convenience would be to add a force commit method in > RandomIndexWriter. This will allow writing tests where segment sizes can be > accurately controlled. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840777#comment-16840777 ] Noble Paul commented on SOLR-13331: --- bq. I couldn't of said it better myself. Very concerning. After the bugs surfaced I realized one thing , almost none of our tests use javabin which is the most commonly used format . if we had any of these tests using javabin, it could've been caught and rectified. We need to ensure that tests run with javabin too. > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch, pull-request-available, ready-to-commit, test > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, > SOLR-13331.patch > > Time Spent: 20m > Remaining Estimate: 0h > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13468) autoscaling/suggestions should be able to give suggestions from payload
[
https://issues.apache.org/jira/browse/SOLR-13468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840797#comment-16840797
]
ASF subversion and git services commented on SOLR-13468:
Commit c464d8a71946d450beffc3f7ba34dfe81da62e7a in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c464d8a ]
SOLR-13468: autoscaling/suggestions should be able to give suggestions from
config sent as a payload (#678)
* SOLR-13468: autoscaling/suggestions should be able to give suggestions from
config sent as a payload
> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling
> configuration sent as a payload . This is helpful in debugging the system or
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json' -d '{
> "cluster-policy": [
> {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
> ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13468) autoscaling/suggestions should be able to give suggestions from payload
[
https://issues.apache.org/jira/browse/SOLR-13468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840796#comment-16840796
]
ASF subversion and git services commented on SOLR-13468:
Commit c464d8a71946d450beffc3f7ba34dfe81da62e7a in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c464d8a ]
SOLR-13468: autoscaling/suggestions should be able to give suggestions from
config sent as a payload (#678)
* SOLR-13468: autoscaling/suggestions should be able to give suggestions from
config sent as a payload
> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling
> configuration sent as a payload . This is helpful in debugging the system or
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json' -d '{
> "cluster-policy": [
> {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
> ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-13463) Solr admin user credentials defined with -Dbasicauth property during start is visible in admin UI to any user.
[ https://issues.apache.org/jira/browse/SOLR-13463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-13463. Resolution: Workaround > Solr admin user credentials defined with -Dbasicauth property during start is > visible in admin UI to any user. > -- > > Key: SOLR-13463 > URL: https://issues.apache.org/jira/browse/SOLR-13463 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 7.7.1 > Environment: QA >Reporter: Vinodh >Priority: Major > Labels: admin-interface, credentials > > We have configured Solr basic authentication in our environment and used > Dbasicauth property to define username:password. Since these property will be > added to Solr startup, the Solr admin username & password details defined > with -Dbasicauth property are displayed in plain text format to all users who > are able to login into admin UI interface in JVM & Java properties sections. > So even a read user who has privileges to login admin UI can able to see > admin user username & password details. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12999) Index replication could delete segments first
[
https://issues.apache.org/jira/browse/SOLR-12999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840792#comment-16840792
]
ASF subversion and git services commented on SOLR-12999:
Commit bf8c6ea435a39564d2a7de5c37cc9e522ca5b9cb in lucene-solr's branch
refs/heads/jira/SOLR-13468 from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bf8c6ea ]
SOLR-12999: Harden TestReplicationHandlerDiskOverFlow against sporadic timing
failures
- ensure IndexFetcher injection is reset in @After method
- replace System.out with Logger
- Log and fail on any exceptions in any callbacks/threads
- use CyclicBarrier (instead of CountdownLatch) to ensure the Query Thread
loop doesn't monopolize
CPU preventing IndexFetcher callback from ever being run
(Some of these improvements directly address jenkins failures we've been seeing)
> Index replication could delete segments first
> -
>
> Key: SOLR-12999
> URL: https://issues.apache.org/jira/browse/SOLR-12999
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: replication (java)
>Reporter: David Smiley
>Assignee: Noble Paul
>Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-12999.patch, SOLR-12999.patch
>
>
> Index replication could optionally delete files that it knows will not be
> needed _first_. This would reduce disk capacity requirements of Solr, and it
> would reduce some disk fragmentation when space get tight.
> Solr (IndexFetcher) already grabs the remote file list, and it could see
> which files it has locally, then delete the others. Today it asks Lucene to
> {{deleteUnusedFiles}} at the end. This new mode would probably only be
> useful if there is no SolrIndexSearcher open, since it would prevent the
> removal of files.
> The motivating scenario is a SolrCloud replica that is going into full
> recovery. It ought to not be fielding searches. The code changes would not
> depend on SolrCloud though.
> This option would have some danger the user should be aware of. If the
> replication fails, leaving the local files incomplete/corrupt, the only
> recourse is to try full replication again. You can't just give up and field
> queries.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-11558) It would be nice if the Graph section of the Cloud tab in the Admin UI could give some more information about the replicas of a collection
[ https://issues.apache.org/jira/browse/SOLR-11558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840794#comment-16840794 ] ASF subversion and git services commented on SOLR-11558: Commit 9ff5eb30af846f2396230606bcffe2862ca7f528 in lucene-solr's branch refs/heads/jira/SOLR-13468 from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9ff5eb3 ] SOLR-11558: It would be nice if the Graph section of the Cloud tab in the Admin UI could give some more information about the replicas of a collection > It would be nice if the Graph section of the Cloud tab in the Admin UI could > give some more information about the replicas of a collection > -- > > Key: SOLR-11558 > URL: https://issues.apache.org/jira/browse/SOLR-11558 > Project: Solr > Issue Type: Wish > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Reporter: Tomás Fernández Löbbe >Assignee: Erick Erickson >Priority: Minor > Fix For: master (9.0), 8.2 > > Attachments: SOLR-11558.patch > > > Right now it lists the nodes where they are hosted, the state and if they are > or not leader. I usually find the need to see more, like the replica and core > names and the replica type, and I find myself moving between this view and > the “tree” view. > I thought about two options: > # A mouse over action that lists the additional information (after some time > of holding the mouse pointer on top of the replica) > # Modify the click action to display this information (right now the click > sends you to the admin UI of that particular replica) > The same could be done to display some extra information of the shard (like > active/inactive, routing range) and the collection (autoAddReplicas, > maxShardsPerNode, configset, etc) -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13440) Support saving/restoring state of the SimCloudManager for repeatable simulations
[
https://issues.apache.org/jira/browse/SOLR-13440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840793#comment-16840793
]
ASF subversion and git services commented on SOLR-13440:
Commit 7ef5d5fe5f39f3cbea3342827f60eb181fb88a19 in lucene-solr's branch
refs/heads/jira/SOLR-13468 from Chris M. Hostetter
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=7ef5d5f ]
SOLR-13440: fix precommit failures
> Support saving/restoring state of the SimCloudManager for repeatable
> simulations
>
>
> Key: SOLR-13440
> URL: https://issues.apache.org/jira/browse/SOLR-13440
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Andrzej Bialecki
>Assignee: Andrzej Bialecki
>Priority: Major
> Attachments: SOLR-13440.patch, SOLR-13440.patch
>
>
> In order to run simulated experiments that test variations in autoscaling
> configs and their impact on the cluster layout we need to be able to start
> from a known well-defined state.
> Currently the {{bin/solr autoscaling -simulate}} tool supports getting the
> initial state from an actual running cluster. This issue proposes adding
> support for saving and restoring this state from local files for running
> repeatable experiments.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13468) autoscaling/suggestions should be able to give suggestions from payload
[
https://issues.apache.org/jira/browse/SOLR-13468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840795#comment-16840795
]
ASF subversion and git services commented on SOLR-13468:
Commit 8118a3c0609ae061d91178d42ee5ea7ccc89be7b in lucene-solr's branch
refs/heads/jira/SOLR-13468 from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8118a3c ]
Merge branch 'master' into jira/SOLR-13468
> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling
> configuration sent as a payload . This is helpful in debugging the system or
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json' -d '{
> "cluster-policy": [
> {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
> ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul merged pull request #678: SOLR-13468: autoscaling/suggestions should be able to give suggestions from config sent as a payload
noblepaul merged pull request #678: SOLR-13468: autoscaling/suggestions should be able to give suggestions from config sent as a payload URL: https://github.com/apache/lucene-solr/pull/678 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13462) Impossible to use solr.MorfologikFilterFactory with ukrainian.dict
[
https://issues.apache.org/jira/browse/SOLR-13462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840791#comment-16840791
]
ASF subversion and git services commented on SOLR-13462:
Commit 3764c727e5649c1af028dee3b14ea5e5b183edb1 in lucene-solr's branch
refs/heads/jira/SOLR-13468 from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3764c72 ]
SOLR-13462: Update dependency definitions to include Ukrainian dictionary.
> Impossible to use solr.MorfologikFilterFactory with ukrainian.dict
> --
>
> Key: SOLR-13462
> URL: https://issues.apache.org/jira/browse/SOLR-13462
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, Schema and Analysis
>Affects Versions: 6.6, 6.6.6, 7.7, 7.7.1, 8.0
>Reporter: Markus Kalkbrenner
>Assignee: Dawid Weiss
>Priority: Major
> Fix For: master (9.0), 8.2
>
>
> First of all, the documentation is wrong. For example
> [https://lucene.apache.org/solr/guide/7_7/language-analysis.html#ukrainian]
> {quote}{{dictionary}}(required) lemmatizer dictionary - the
> {{lucene-analyzers-morfologik}} jar contains a Ukrainian dictionary at
> {{org/apache/lucene/analysis/uk/ukrainian.dict}}.
> {quote}
>
> {{{color:#008000} {color:#7d9029}class={color}{color:#ba2121}"solr.MorfologikFilterFactory"{color}
>
> {color:#7d9029}dictionary={color}{color:#ba2121}"org/apache/lucene/analysis/uk/ukrainian.dict"{color}{color:#008000}/>{color}}}
>
> Both parts are wrong. There's no {{{color:#ba2121}ukrainian.dict{color}}} at
> this path. I assume that this is caused by the commit of LUCENE-7785.
> So I know that the dictionary has been moved but I can't find it anywhere in
> the distribution download!
> Unfortunately adding custom jars to a hosted Solr environment is not possible
> and therefore existing installations could not be upgraded.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13468) autoscaling/suggestions should be able to give suggestions from payload
[
https://issues.apache.org/jira/browse/SOLR-13468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840833#comment-16840833
]
ASF subversion and git services commented on SOLR-13468:
Commit 82ede903f64812053ed81ee2e42ed94101e6e091 in lucene-solr's branch
refs/heads/master from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=82ede90 ]
SOLR-13468: added ref-guide
> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling
> configuration sent as a payload . This is helpful in debugging the system or
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json' -d '{
> "cluster-policy": [
> {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
> ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11.0.2) - Build # 24085 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24085/ Java: 64bit/jdk-11.0.2 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC 3 tests failed. FAILED: junit.framework.TestSuite.org.apache.solr.cloud.TestCloudSearcherWarming Error Message: 5 threads leaked from SUITE scope at org.apache.solr.cloud.TestCloudSearcherWarming: 1) Thread[id=32715, name=ZkTestServer Run Thread, state=WAITING, group=TGRP-TestCloudSearcherWarming] at java.base@11.0.2/java.lang.Object.wait(Native Method) at java.base@11.0.2/java.lang.Thread.join(Thread.java:1305) at java.base@11.0.2/java.lang.Thread.join(Thread.java:1379) at app//org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:320) at app//org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:343) at app//org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:566)2) Thread[id=32719, name=ProcessThread(sid:0 cport:42947):, state=WAITING, group=TGRP-TestCloudSearcherWarming] at java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.2/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at app//org.apache.zookeeper.server.PrepRequestProcessor.run(PrepRequestProcessor.java:123) 3) Thread[id=32718, name=SyncThread:0, state=WAITING, group=TGRP-TestCloudSearcherWarming] at java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.2/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at app//org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:127) 4) Thread[id=32716, name=NIOServerCxn.Factory:0.0.0.0/0.0.0.0:0, state=RUNNABLE, group=TGRP-TestCloudSearcherWarming] at java.base@11.0.2/sun.nio.ch.EPoll.wait(Native Method) at java.base@11.0.2/sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:120) at java.base@11.0.2/sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:124) at java.base@11.0.2/sun.nio.ch.SelectorImpl.select(SelectorImpl.java:136) at app//org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:203) at java.base@11.0.2/java.lang.Thread.run(Thread.java:834)5) Thread[id=32717, name=SessionTracker, state=TIMED_WAITING, group=TGRP-TestCloudSearcherWarming] at java.base@11.0.2/java.lang.Object.wait(Native Method) at app//org.apache.zookeeper.server.SessionTrackerImpl.run(SessionTrackerImpl.java:147) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 5 threads leaked from SUITE scope at org.apache.solr.cloud.TestCloudSearcherWarming: 1) Thread[id=32715, name=ZkTestServer Run Thread, state=WAITING, group=TGRP-TestCloudSearcherWarming] at java.base@11.0.2/java.lang.Object.wait(Native Method) at java.base@11.0.2/java.lang.Thread.join(Thread.java:1305) at java.base@11.0.2/java.lang.Thread.join(Thread.java:1379) at app//org.apache.zookeeper.server.NIOServerCnxnFactory.join(NIOServerCnxnFactory.java:320) at app//org.apache.solr.cloud.ZkTestServer$ZKServerMain.runFromConfig(ZkTestServer.java:343) at app//org.apache.solr.cloud.ZkTestServer$2.run(ZkTestServer.java:566) 2) Thread[id=32719, name=ProcessThread(sid:0 cport:42947):, state=WAITING, group=TGRP-TestCloudSearcherWarming] at java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.2/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at app//org.apache.zookeeper.server.PrepRequestProcessor.run(PrepRequestProcessor.java:123) 3) Thread[id=32718, name=SyncThread:0, state=WAITING, group=TGRP-TestCloudSearcherWarming] at java.base@11.0.2/jdk.internal.misc.Unsafe.park(Native Method) at java.base@11.0.2/java.util.concurrent.locks.LockSupport.park(LockSupport.java:194) at java.base@11.0.2/java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2081) at java.base@11.0.2/java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:433) at
[jira] [Comment Edited] (SOLR-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840777#comment-16840777 ] Noble Paul edited comment on SOLR-13331 at 5/15/19 9:23 PM: bq. I couldn't of said it better myself. Very concerning. After the bugs surfaced I realized one thing , almost none of our tests use javabin which is the most commonly used format . if we had any of these tests using javabin, it could've been caught and rectified. Interestingly most of them still use XML which nobody uses We need to ensure that tests run with json+ javabin too. was (Author: noble.paul): bq. I couldn't of said it better myself. Very concerning. After the bugs surfaced I realized one thing , almost none of our tests use javabin which is the most commonly used format . if we had any of these tests using javabin, it could've been caught and rectified. We need to ensure that tests run with javabin too. > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch, pull-request-available, ready-to-commit, test > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, > SOLR-13331.patch > > Time Spent: 20m > Remaining Estimate: 0h > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13472) HTTP requests to a node that does not hold a core of the collection are unauthorized
[
https://issues.apache.org/jira/browse/SOLR-13472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840800#comment-16840800
]
Noble Paul commented on SOLR-13472:
---
which is the version of Solr you are using?
> HTTP requests to a node that does not hold a core of the collection are
> unauthorized
>
>
> Key: SOLR-13472
> URL: https://issues.apache.org/jira/browse/SOLR-13472
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authorization
>Affects Versions: 7.7.1, 8.0
>Reporter: adfel
>Priority: Minor
> Labels: security
>
> When creating collection in SolrCloud, collection is available for queries
> and updates through all Solr nodes, in particular nodes that does not hold
> one of collection's cores. This is expected behaviour that works when using
> SolrJ client or HTTP requests.
> When enabling authorization rules it seems that this behaviour is broken for
> HTTP requests:
> - executing request to a node that holds part of the collection (core) obey
> to authorization rules as expected.
> - other nodes respond with code 403 - unauthorized request.
> SolrJ still works as expected.
> Tested both with BasicAuthPlugin and KerberosPlugin authentication plugins.
> +Steps for reproduce:+
> 1. Create a cloud made of 2 nodes (node_1, node_2).
> 2. Configure authentication and authorization by uploading following
> security.json file to zookeeper:
>
> {code:java}
> {
> "authentication": {
>"blockUnknown": true,
>"class": "solr.BasicAuthPlugin",
>"credentials": {
> "solr": "'solr' user password_hash",
> "indexer_app": "'indexer_app' password_hash",
> "read_user": "'read_user' password_hash"
>}
> },
> "authorization": {
>"class": "solr.RuleBasedAuthorizationPlugin",
>"permissions": [
> {
>"name": "read",
>"role": "*"
> },
> {
>"name": "update",
>"role": [
> "indexer",
> "admin"
>]
> },
> {
>"name": "all",
>"role": "admin"
> }
>],
>"user-role": {
> "solr": "admin",
> "indexer_app": "indexer"
>}
> }
> }{code}
>
> 3. create 'test' collection with one shard on *node_1*.
> --
> The following requests expected to succeed but return 403 status
> (unauthorized request):
> {code:java}
> curl -u read_user:read_user "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/update?commit=true;
> {code}
>
> Authenticated '_solr_' user requests works as expected. My guess is due to
> the special '_all_' role.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-8757) Better Segment To Thread Mapping Algorithm
[ https://issues.apache.org/jira/browse/LUCENE-8757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840683#comment-16840683 ] Atri Sharma commented on LUCENE-8757: - Hi [~jpountz], I was going through IndexSearcher code and see that there are no checks that we do in IndexSearcher to ensure that LeafReaderContexts are ordered by docID. Should we add those checks while constructing a new instance? I think that can be orthogonal to this patch, since this patch anyways orders leaf slices by docIDs. WDYT? > Better Segment To Thread Mapping Algorithm > -- > > Key: LUCENE-8757 > URL: https://issues.apache.org/jira/browse/LUCENE-8757 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Atri Sharma >Assignee: Simon Willnauer >Priority: Major > Attachments: LUCENE-8757.patch, LUCENE-8757.patch, LUCENE-8757.patch, > LUCENE-8757.patch, LUCENE-8757.patch > > > The current segments to threads allocation algorithm always allocates one > thread per segment. This is detrimental to performance in case of skew in > segment sizes since small segments also get their dedicated thread. This can > lead to performance degradation due to context switching overheads. > > A better algorithm which is cognizant of size skew would have better > performance for realistic scenarios -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Lucene/Solr 8.1
The artifacts are available, and maven repos have synced up. However, I had to undertake some unscheduled travel and wasn't able to send out the announcement and website update today. I'll do this tomorrow. On Tue, May 7, 2019 at 9:38 PM Ishan Chattopadhyaya wrote: > > I've reverted SOLR-13449 and proceeding for RC1. > > On Tue, May 7, 2019 at 7:35 PM Jan Høydahl wrote: > > > > The JWTAuthPluginIntegrationTest.createCollectionUpdateAndQueryDistributed > > tests failing rely on polling metrics from all nodes in the cluster, sum > > the counts and assert that the count is above a certain threshold. I saw > > one test that expected 12 for the authenticated requests counter, but got > > only 4. Could it perhaps be that when the client always did 3 or 5 requests > > to the nodes to fetch metrics, it would take more time, and now that we get > > results on first attempt we may get into timing issues where Metrics store > > is not yet updated? Have not checked in depth though. > > > > -- > > Jan Høydahl, search solution architect > > Cominvent AS - www.cominvent.com > > > > 7. mai 2019 kl. 15:44 skrev Ishan Chattopadhyaya > > : > > > > Jenkins has caught up with what I was seeing: : > > https://jenkins.thetaphi.de/job/Lucene-Solr-8.1-Linux/296/ > > > > On Tue, May 7, 2019 at 7:08 PM Ishan Chattopadhyaya > > wrote: > > > > > > Seems to me that the last moment commit for SOLR-13449 in branch_8_1 > > has resulted in the failure. > > BTW, I'm not seeing this failure on branch_8x (contrary to what I > > wrote above; I must've been hallucinating). > > I'll see if something quick can be done to fix this, otherwise I'll > > revert this change and spin the RC. > > > > On Tue, May 7, 2019 at 5:04 PM Ishan Chattopadhyaya > > wrote: > > > > > > Seems similar to > > https://issues.apache.org/jira/browse/SOLR-13248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769078#comment-16769078 > > Looking into it further. > > > > On Tue, May 7, 2019 at 5:01 PM Ishan Chattopadhyaya > > wrote: > > > > > > On my systems (JDK 8), the following test is failing 100% in branch_8x > > and branch_8_1. Seems like this is not the case in Jenkins. > > > > ant -Dtestcase=TestSolrCloudWithHadoopAuthPlugin test > > > > Looking into what could be wrong with my system. Has anyone > > seen/experienced this before? > > > > On Tue, May 7, 2019 at 3:04 PM Ishan Chattopadhyaya > > wrote: > > > > > > As Đạt mentioned in this issue, nothing more needs to be done for 8.1. > > I'm starting with the RC building. > > > > On Tue, May 7, 2019 at 2:58 PM Ishan Chattopadhyaya > > wrote: > > > > > > I'll spin the RC as soon as SOLR-13276 is pushed to the branch. > > > > On Tue, May 7, 2019 at 1:03 AM Ishan Chattopadhyaya > > wrote: > > > > > > Provided there are no reproducible failures, I'll spin up an RC in > > 12-16 hours time. > > > > On Fri, May 3, 2019 at 5:35 PM Ishan Chattopadhyaya > > wrote: > > > > > > No problem and thanks Uwe! > > > > On Fri, 3 May, 2019, 5:33 PM Uwe Schindler, wrote: > > > > > > 8.1 Jobs are running on Jenkins since this morning - sorry for the delay. > > > > Uwe > > > > - > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > -Original Message- > > From: Ishan Chattopadhyaya > > Sent: Wednesday, May 1, 2019 11:54 AM > > To: Lucene Dev > > Subject: Re: Lucene/Solr 8.1 > > > > I've cut the release branch, branch_8_1. > > Seems like I don't have authorization to create a new Jenkins job for > > 8.1. Can someone with the access please help? > > > > On Tue, Apr 30, 2019 at 9:48 PM Ishan Chattopadhyaya > > wrote: > > > > > > Hi all, > > I'll cut the release branch in around 12-18 hours. > > Planning to build the first RC on 2nd May. > > Thanks and regards, > > Ishan > > > > On Fri, Apr 19, 2019 at 12:04 AM Joel Bernstein > > > > wrote: > > > > > > +1 to April 30th timeframe. > > > > On Thu, Apr 18, 2019 at 12:40 PM Erick Erickson > > > > wrote: > > > > > > 30 Apr seems reasonable to me for cutting the branch. > > > > Thanks! > > > > On Apr 18, 2019, at 9:23 AM, Ishan Chattopadhyaya > > > > wrote: > > > > > > I'm expecting > > you'd build a RC soon after cutting the branch? > > > > > > Sure, maybe a day or two after the branch cutting. > > > > > > On Wed, Apr 17, 2019 at 8:51 PM Adrien Grand > > > > wrote: > > > > > > +1 to do a 8.1 soon too, thanks Ishan for volunteering! I'm expecting > > you'd build a RC soon after cutting the branch? > > > > On Wed, Apr 17, 2019 at 10:08 AM Ishan Chattopadhyaya > > wrote: > > > > > > +1 for a 8.1 soon. I can volunteer for RM. > > Does 30 April (about 2 weeks from now) sound reasonable for a > > > > branch cutting? > > > > > > On Wed, Apr 17, 2019 at 1:14 PM Ignacio Vera > > > > wrote: > > > > > > Hi all, > > > > Feature freeze for 8.0 was long time ago (January 29th) and there > > > > is interesting stuff that has not been released yet. In Lucene in particular > > there is the new
[jira] [Commented] (SOLR-13463) Solr admin user credentials defined with -Dbasicauth property during start is visible in admin UI to any user.
[ https://issues.apache.org/jira/browse/SOLR-13463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840738#comment-16840738 ] Jan Høydahl commented on SOLR-13463: You MUST use SSL together with Basic auth. You find instructions in Solr reference guide on how to enable SSL for your cluster. > Solr admin user credentials defined with -Dbasicauth property during start is > visible in admin UI to any user. > -- > > Key: SOLR-13463 > URL: https://issues.apache.org/jira/browse/SOLR-13463 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI >Affects Versions: 7.7.1 > Environment: QA >Reporter: Vinodh >Priority: Major > Labels: admin-interface, credentials > > We have configured Solr basic authentication in our environment and used > Dbasicauth property to define username:password. Since these property will be > added to Solr startup, the Solr admin username & password details defined > with -Dbasicauth property are displayed in plain text format to all users who > are able to login into admin UI interface in JVM & Java properties sections. > So even a read user who has privileges to login admin UI can able to see > admin user username & password details. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13472) HTTP requests to a node that does not hold a core of the collection are unauthorized
[
https://issues.apache.org/jira/browse/SOLR-13472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840760#comment-16840760
]
Jason Gerlowski commented on SOLR-13472:
I haven't tried out your example yet, so I can't speak to what is causing the
behavior you're seeing. I hope to look into it soon.
But I can offer one point of clarification on why the behavior might differ in
SolrJ vs a curl request. I suspect what's happening is that your SolrJ code
makes use of CloudSolrClient. CloudSolrClient is data-aware for collections,
meaning that it makes requests directly to the nodes hosting your data (saving
users some extra hops). So if the behavior is only triggered when a request
arrives at a node that _doesnt_ host your data, it makes sense that SolrJ (or
at least CloudSolrClient) is unable to trigger it.
> HTTP requests to a node that does not hold a core of the collection are
> unauthorized
>
>
> Key: SOLR-13472
> URL: https://issues.apache.org/jira/browse/SOLR-13472
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authorization
>Affects Versions: 7.7.1, 8.0
>Reporter: adfel
>Priority: Minor
> Labels: security
>
> When creating collection in SolrCloud, collection is available for queries
> and updates through all Solr nodes, in particular nodes that does not hold
> one of collection's cores. This is expected behaviour that works when using
> SolrJ client or HTTP requests.
> When enabling authorization rules it seems that this behaviour is broken for
> HTTP requests:
> - executing request to a node that holds part of the collection (core) obey
> to authorization rules as expected.
> - other nodes respond with code 403 - unauthorized request.
> SolrJ still works as expected.
> Tested both with BasicAuthPlugin and KerberosPlugin authentication plugins.
> +Steps for reproduce:+
> 1. Create a cloud made of 2 nodes (node_1, node_2).
> 2. Configure authentication and authorization by uploading following
> security.json file to zookeeper:
>
> {code:java}
> {
> "authentication": {
>"blockUnknown": true,
>"class": "solr.BasicAuthPlugin",
>"credentials": {
> "solr": "'solr' user password_hash",
> "indexer_app": "'indexer_app' password_hash",
> "read_user": "'read_user' password_hash"
>}
> },
> "authorization": {
>"class": "solr.RuleBasedAuthorizationPlugin",
>"permissions": [
> {
>"name": "read",
>"role": "*"
> },
> {
>"name": "update",
>"role": [
> "indexer",
> "admin"
>]
> },
> {
>"name": "all",
>"role": "admin"
> }
>],
>"user-role": {
> "solr": "admin",
> "indexer_app": "indexer"
>}
> }
> }{code}
>
> 3. create 'test' collection with one shard on *node_1*.
> --
> The following requests expected to succeed but return 403 status
> (unauthorized request):
> {code:java}
> curl -u read_user:read_user "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/select?q=*:*;
> curl -u indexer_app:indexer_app "http://node_2/solr/test/update?commit=true;
> {code}
>
> Authenticated '_solr_' user requests works as expected. My guess is due to
> the special '_all_' role.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-13331) Atomic Update Multivalue remove does not work
[ https://issues.apache.org/jira/browse/SOLR-13331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840777#comment-16840777 ] Noble Paul edited comment on SOLR-13331 at 5/15/19 9:28 PM: bq. I couldn't of said it better myself. Very concerning. After the bugs surfaced I realized one thing , almost none of our tests use javabin which is the most commonly used format . if we had any of these tests using javabin, it could've been caught and rectified. Interestingly most of them still use XML which nobody uses We need to ensure that tests run with json+ javabin too. I've just created SOLR-13473 was (Author: noble.paul): bq. I couldn't of said it better myself. Very concerning. After the bugs surfaced I realized one thing , almost none of our tests use javabin which is the most commonly used format . if we had any of these tests using javabin, it could've been caught and rectified. Interestingly most of them still use XML which nobody uses We need to ensure that tests run with json+ javabin too. > Atomic Update Multivalue remove does not work > - > > Key: SOLR-13331 > URL: https://issues.apache.org/jira/browse/SOLR-13331 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: UpdateRequestProcessors >Affects Versions: 7.7, 7.7.1, 8.0 > Environment: Standalone Solr Server >Reporter: Thomas Wöckinger >Assignee: Jason Gerlowski >Priority: Critical > Labels: patch, pull-request-available, ready-to-commit, test > Fix For: 7.7.2, 8.1, master (9.0) > > Attachments: Fix-SOLR13331-Add-toNativeType-implementations.patch, > SOLR-13331.patch > > Time Spent: 20m > Remaining Estimate: 0h > > When using JavaBinCodec the values of collections are of type > ByteArrayUtf8CharSequence, existing field values are Strings so the remove > Operation does not have any effect. > The relevant code is located in class AtomicUpdateDocumentMerger method > doRemove. > The method parameter fieldVal contains the collection values of type > ByteArrayUtf8CharSequence, the variable original contains the collection of > Strings -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13473) Ensure that the tests use JSON,javabin to update docs
Noble Paul created SOLR-13473:
-
Summary: Ensure that the tests use JSON,javabin to update docs
Key: SOLR-13473
URL: https://issues.apache.org/jira/browse/SOLR-13473
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Noble Paul
{{SolrTestCaseJ4#assertU}} sends documents as XML. XML is a very uncommon
update format .
We should change it to use JSON/javabin
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13468) autoscaling/suggestions should be able to give suggestions from payload
[
https://issues.apache.org/jira/browse/SOLR-13468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840832#comment-16840832
]
ASF subversion and git services commented on SOLR-13468:
Commit 8f9c3e88755dbe95a268e43064d29db3e7d9a49c in lucene-solr's branch
refs/heads/branch_8x from Noble Paul
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8f9c3e8 ]
SOLR-13468: added ref-guide
> autoscaling/suggestions should be able to give suggestions from payload
> ---
>
> Key: SOLR-13468
> URL: https://issues.apache.org/jira/browse/SOLR-13468
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Noble Paul
>Assignee: Noble Paul
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There are cases where users would want to get the suggestion from autoscaling
> configuration sent as a payload . This is helpful in debugging the system or
> get alternate suggestions based on different config.
> {code:java}
> curl -X POST -H 'Content-type:application/json' -d '{
> "cluster-policy": [
> {"replica": "#EQUAL", "shard": "#EACH", "sysprop.zone": ["east", "west"]}
> ]
> }' http://localhost:8983/api/cluster/autoscaling/suggestions
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-reference-guide-8.x - Build # 2973 - Failure
Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2973/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 8f9c3e88755dbe95a268e43064d29db3e7d9a49c
(refs/remotes/origin/branch_8x)
> git config core.sparsecheckout # timeout=10
> git checkout -f 8f9c3e88755dbe95a268e43064d29db3e7d9a49c
Commit message: "SOLR-13468: added ref-guide"
> git rev-list --no-walk 92ff7283727d7e7abf7c71da61170d1e4c2004db # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins8198780379214244707.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
[JENKINS] Solr-reference-guide-master - Build # 15901 - Failure
Build: https://builds.apache.org/job/Solr-reference-guide-master/15901/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 82ede903f64812053ed81ee2e42ed94101e6e091
(refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 82ede903f64812053ed81ee2e42ed94101e6e091
Commit message: "SOLR-13468: added ref-guide"
> git rev-list --no-walk c464d8a71946d450beffc3f7ba34dfe81da62e7a # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins7535830877095168437.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
[JENKINS] Lucene-Solr-NightlyTests-7.7 - Build # 12 - Still Unstable
Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-7.7/12/ 1 tests failed. FAILED: org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv_idx Error Message: expected:<815> but was:<862> Stack Trace: java.lang.AssertionError: expected:<815> but was:<862> at __randomizedtesting.SeedInfo.seed([830E38476CC7F41:9D4C964CAA10D2A0]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.checkField(TestStressCloudBlindAtomicUpdates.java:282) at org.apache.solr.cloud.TestStressCloudBlindAtomicUpdates.test_dv_idx(TestStressCloudBlindAtomicUpdates.java:241) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.lang.Thread.run(Thread.java:748) Build Log: [...truncated 13224 lines...] [junit4] Suite:
[JENKINS] Solr-reference-guide-8.x - Build # 2974 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2974/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 8f9c3e88755dbe95a268e43064d29db3e7d9a49c
(refs/remotes/origin/branch_8x)
> git config core.sparsecheckout # timeout=10
> git checkout -f 8f9c3e88755dbe95a268e43064d29db3e7d9a49c
Commit message: "SOLR-13468: added ref-guide"
> git rev-list --no-walk 8f9c3e88755dbe95a268e43064d29db3e7d9a49c # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins8776174368703974999.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
[JENKINS] Solr-reference-guide-8.x - Build # 2977 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2977/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 6a3d32728b784dbba66f6e917d6d277b915d9c72
(refs/remotes/origin/branch_8x)
> git config core.sparsecheckout # timeout=10
> git checkout -f 6a3d32728b784dbba66f6e917d6d277b915d9c72
Commit message: "SOLR-13467: Include the S2 Geometry lib to make it simpler to
use prefixTree="s2" on a Geo3D spatial field. * Improved documentation on
Geo3D. * Better testing for Geo3D."
> git rev-list --no-walk 8f9c3e88755dbe95a268e43064d29db3e7d9a49c # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins3092809662476408078.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using
[JENKINS] Solr-reference-guide-master - Build # 15906 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-master/15906/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 3a88ab616c9c8debe1f3a10e291697083eda3342
(refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 3a88ab616c9c8debe1f3a10e291697083eda3342
Commit message: "SOLR-13467: Include the S2 Geometry lib to make it simpler to
use prefixTree="s2" on a Geo3D spatial field. * Improved documentation on
Geo3D. * Better testing for Geo3D."
> git rev-list --no-walk 3a88ab616c9c8debe1f3a10e291697083eda3342 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins1519414812165793474.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using
[JENKINS] Lucene-Solr-master-Windows (64bit/jdk-12) - Build # 7944 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Windows/7944/ Java: 64bit/jdk-12 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 2035 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\temp\junit4-J1-20190516_031046_4485095654682083157638.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\core\test\temp\junit4-J0-20190516_031046_4488201210043228032720.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 316 lines...] [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\temp\junit4-J0-20190516_032112_37113620066504469158532.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\test-framework\test\temp\junit4-J1-20190516_032112_371973017354982954308.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 1076 lines...] [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\temp\junit4-J0-20190516_032247_382343726105722900864.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\common\test\temp\junit4-J1-20190516_032247_3823131355661003433939.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 243 lines...] [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\icu\test\temp\junit4-J0-20190516_032654_17210798567764898610297.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [...truncated 3 lines...] [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\icu\test\temp\junit4-J1-20190516_032654_17316554481377157367157.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 253 lines...] [junit4] JVM J0: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\kuromoji\test\temp\junit4-J0-20190516_032717_76210509159220602621493.syserr [junit4] >>> JVM J0 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J0: EOF [junit4] JVM J1: stderr was not empty, see: C:\Users\jenkins\workspace\Lucene-Solr-master-Windows\lucene\build\analysis\kuromoji\test\temp\junit4-J1-20190516_032717_76216350145029986360445.syserr [junit4] >>> JVM J1 emitted unexpected output (verbatim) [junit4] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release. [junit4] <<< JVM J1: EOF [...truncated 155 lines...] [junit4] JVM J0: stderr was not empty, see:
[JENKINS] Lucene-Solr-repro - Build # 3263 - Unstable
Build: https://builds.apache.org/job/Lucene-Solr-repro/3263/ [...truncated 29 lines...] [repro] Jenkins log URL: https://builds.apache.org/job/Lucene-Solr-NightlyTests-8.x/98/consoleText [repro] Revision: f6774a2b6eb731347c9fef48749c8610f53ab079 [repro] Ant options: -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt [repro] Repro line: ant test -Dtestcase=HdfsAutoAddReplicasIntegrationTest -Dtests.method=testSimple -Dtests.seed=B737CA645E895219 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=en-US -Dtests.timezone=Europe/Busingen -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [repro] git rev-parse --abbrev-ref HEAD [repro] git rev-parse HEAD [repro] Initial local git branch/revision: 82ede903f64812053ed81ee2e42ed94101e6e091 [repro] git fetch [repro] git checkout f6774a2b6eb731347c9fef48749c8610f53ab079 [...truncated 2 lines...] [repro] git merge --ff-only [...truncated 1 lines...] [repro] ant clean [...truncated 6 lines...] [repro] Test suites by module: [repro]solr/core [repro] HdfsAutoAddReplicasIntegrationTest [repro] ant compile-test [...truncated 3583 lines...] [repro] ant test-nocompile -Dtests.dups=5 -Dtests.maxfailures=5 -Dtests.class="*.HdfsAutoAddReplicasIntegrationTest" -Dtests.showOutput=onerror -Dtests.multiplier=2 -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.seed=B737CA645E895219 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true -Dtests.linedocsfile=/home/jenkins/jenkins-slave/workspace/Lucene-Solr-NightlyTests-8.x/test-data/enwiki.random.lines.txt -Dtests.locale=en-US -Dtests.timezone=Europe/Busingen -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1 [...truncated 2478 lines...] [repro] Setting last failure code to 256 [repro] Failures: [repro] 1/5 failed: org.apache.solr.cloud.autoscaling.HdfsAutoAddReplicasIntegrationTest [repro] git checkout 82ede903f64812053ed81ee2e42ed94101e6e091 [...truncated 2 lines...] [repro] Exiting with code 256 [...truncated 6 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-reference-guide-master - Build # 15902 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-master/15902/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 82ede903f64812053ed81ee2e42ed94101e6e091
(refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 82ede903f64812053ed81ee2e42ed94101e6e091
Commit message: "SOLR-13468: added ref-guide"
> git rev-list --no-walk 82ede903f64812053ed81ee2e42ed94101e6e091 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins8562240153376369170.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
[jira] [Updated] (LUCENE-8800) FieldsReader#terms poor performance on a index with many field names sharing common prefix
[
https://issues.apache.org/jira/browse/LUCENE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Huy Le updated LUCENE-8800:
---
Summary: FieldsReader#terms poor performance on a index with many field
names sharing common prefix (was: FieldsReader#terms poor performance on a
index with many fields)
> FieldsReader#terms poor performance on a index with many field names sharing
> common prefix
> --
>
> Key: LUCENE-8800
> URL: https://issues.apache.org/jira/browse/LUCENE-8800
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Affects Versions: 8.0
>Reporter: Huy Le
>Priority: Major
> Attachments: Screen Shot 2019-05-15 at 5.08.26 pm.png
>
>
> We have experienced poor performance on an index with many fields, their
> names share common prefix. Sampling stack using jprofiler showed a hotspot on
> method FieldsReader#terms.
> !Screen Shot 2019-05-15 at 5.08.26 pm.png!
> Looking at source code I have seen that TreeMap is used to map between field
> name to FieldsProducer which means a lookup incurs O(logN) comparisons.
> {code:java}
> private static class FieldsReader extends FieldsProducer {
> ...
> private final Map fields = new TreeMap<>();
> ...
> @Override
> public Terms terms(String field) throws IOException {
> FieldsProducer fieldsProducer = fields.get(field);
> return fieldsProducer == null ? null : fieldsProducer.terms(field);
> }
> {code}
> The problem becomes much worse when field names are long and share common
> prefix because each comparison has to iterate over an entire string.
> In our case, the index has around 6000 fields in form of customfield_*. I
> wonder if we can change the TreeMap to HashMap or LinkedHashMap in case we
> want to preserve the sorted order to improve the situation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-BadApples-Tests-8.x - Build # 102 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-BadApples-Tests-8.x/102/
1 tests failed.
FAILED:
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader
Error Message:
Doc with id=4 not found in
https://127.0.0.1:38151/solr/outOfSyncReplicasCannotBecomeLeader-false due to:
Path not found: /id; rsp={doc=null}
Stack Trace:
java.lang.AssertionError: Doc with id=4 not found in
https://127.0.0.1:38151/solr/outOfSyncReplicasCannotBecomeLeader-false due to:
Path not found: /id; rsp={doc=null}
at
__randomizedtesting.SeedInfo.seed([B3AA42F6379701AA:CD4162E6F4F00E90]:0)
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.solr.cloud.TestCloudConsistency.assertDocExists(TestCloudConsistency.java:283)
at
org.apache.solr.cloud.TestCloudConsistency.assertDocsExistInAllReplicas(TestCloudConsistency.java:267)
at
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader(TestCloudConsistency.java:138)
at
org.apache.solr.cloud.TestCloudConsistency.testOutOfSyncReplicasCannotBecomeLeader(TestCloudConsistency.java:97)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54)
[JENKINS] Solr-reference-guide-master - Build # 15904 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-master/15904/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision bd64ed6d2a87b136f68f322e4db413aa37a5eabc
(refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f bd64ed6d2a87b136f68f322e4db413aa37a5eabc
Commit message: "SOLR-13437: fork noggit code into Solr (#666)"
> git rev-list --no-walk 82ede903f64812053ed81ee2e42ed94101e6e091 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins2603059749637917219.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully
Re: Solr 8.1 issue with collection aliases
Note only an admin UI issue. Access collections via their alias does not work.
> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
>
> It seems creating alias in Solr Admin UI is broken. It's a minor issue for
> 8.1.0
> I've alias via REST call
> http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
> successfully.
> Jörn, thanks for reporting.
>
>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke wrote:
>> Hi,
>>
>> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with
>> collection aliases, but I am not 100% sure it is due to the upgrade.
>>
>> Situation:
>> I have a collection called c_testcollection.
>> I have an alias called testcollection.
>> Alias "testcollection" points to "c_testcollection".
>> On Solr 8.0 no issue
>>
>> After upgrade to Solr 8.1:
>> When I do a query on c_testcollection then there is no issue:
>> http://localhost:8983/solr/c_testcollection/select?q=test
>> When I do a query on testcollection then I receive the stacktrace below
>> http://localhost:8983/solr/testcollection/select?q=test
>>
>> Additionally I observe a strange behavior in the admin ui. When I try to
>> create an alias (e.g. new) for a new collection (e.g. c_new) then it
>> creates two aliases:
>> new => c_new
>> c_new => c_new
>> if i then do a query on the alias new it works without issues. If I remove
>> the alias from c_new to c_new then I get the same error. Is this desired
>> behaviour?
>> It is rather annoying to have unnecessary aliases, because I need to filter
>> them out in my application when retrieving all aliases.
>> Is there a related issue.
>>
>> Here the stacktrace:
>> {
>> "error":{
>> "trace":"java.lang.NullPointerException\n\tat
>> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
>> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
>> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\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:1588)\n\tat
>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\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:502)\n\tat
>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)\n\tat
>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)\n\tat
>> org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:171)\n\tat
>>
[JENKINS] Solr-reference-guide-master - Build # 15905 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-master/15905/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 3a88ab616c9c8debe1f3a10e291697083eda3342
(refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 3a88ab616c9c8debe1f3a10e291697083eda3342
Commit message: "SOLR-13467: Include the S2 Geometry lib to make it simpler to
use prefixTree="s2" on a Geo3D spatial field. * Improved documentation on
Geo3D. * Better testing for Geo3D."
> git rev-list --no-walk bd64ed6d2a87b136f68f322e4db413aa37a5eabc # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins107118509065284865.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #666: SOLR-13437: fork noggit code into Solr
noblepaul commented on a change in pull request #666: SOLR-13437: fork noggit code into Solr URL: https://github.com/apache/lucene-solr/pull/666#discussion_r284491919 ## File path: solr/solrj/src/java/org/apache/solr/common/json/ObjectBuilder.java ## @@ -0,0 +1,166 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more Review comment: done This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8800) FieldsReader#terms poor performance on a index with many fields
[
https://issues.apache.org/jira/browse/LUCENE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Huy Le updated LUCENE-8800:
---
Attachment: (was: Screen Shot 2019-05-15 at 5.08.26 pm.png)
> FieldsReader#terms poor performance on a index with many fields
> ---
>
> Key: LUCENE-8800
> URL: https://issues.apache.org/jira/browse/LUCENE-8800
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Affects Versions: 8.0
>Reporter: Huy Le
>Priority: Major
>
> We have experienced poor performance on an index with many fields, their
> names share common prefix. Sampling stack using jprofiler showed a hotspot on
> method FieldsReader#terms.
> !Screen Shot 2019-05-15 at 5.08.26 pm.png!
> Looking at source code I have seen that TreeMap is used to map between field
> name to FieldsProducer which means a lookup incurs O(logN) comparisons.
> {code:java}
> private static class FieldsReader extends FieldsProducer {
> ...
> private final Map fields = new TreeMap<>();
> ...
> @Override
> public Terms terms(String field) throws IOException {
> FieldsProducer fieldsProducer = fields.get(field);
> return fieldsProducer == null ? null : fieldsProducer.terms(field);
> }
> {code}
> The problem becomes much worse when field names are long and share common
> prefix because each comparison has to iterate over an entire string.
> In our case, the index has around 6000 fields in form of customfield_*. I
> wonder if we can change the TreeMap to HashMap or LinkedHashMap in case we
> want to preserve the sorted order to improve the situation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-8800) FieldsReader#terms poor performance on a index with many fields
[
https://issues.apache.org/jira/browse/LUCENE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Huy Le updated LUCENE-8800:
---
Attachment: Screen Shot 2019-05-15 at 5.08.26 pm.png
> FieldsReader#terms poor performance on a index with many fields
> ---
>
> Key: LUCENE-8800
> URL: https://issues.apache.org/jira/browse/LUCENE-8800
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Affects Versions: 8.0
>Reporter: Huy Le
>Priority: Major
> Attachments: Screen Shot 2019-05-15 at 5.08.26 pm.png
>
>
> We have experienced poor performance on an index with many fields, their
> names share common prefix. Sampling stack using jprofiler showed a hotspot on
> method FieldsReader#terms.
> !Screen Shot 2019-05-15 at 5.08.26 pm.png!
> Looking at source code I have seen that TreeMap is used to map between field
> name to FieldsProducer which means a lookup incurs O(logN) comparisons.
> {code:java}
> private static class FieldsReader extends FieldsProducer {
> ...
> private final Map fields = new TreeMap<>();
> ...
> @Override
> public Terms terms(String field) throws IOException {
> FieldsProducer fieldsProducer = fields.get(field);
> return fieldsProducer == null ? null : fieldsProducer.terms(field);
> }
> {code}
> The problem becomes much worse when field names are long and share common
> prefix because each comparison has to iterate over an entire string.
> In our case, the index has around 6000 fields in form of customfield_*. I
> wonder if we can change the TreeMap to HashMap or LinkedHashMap in case we
> want to preserve the sorted order to improve the situation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-MacOSX (64bit/jdk1.8.0) - Build # 135 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-MacOSX/135/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 62374 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir:
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj330314364
[ecj-lint] Compiling 1272 source files to
/var/folders/qg/h2dfw5s161s51l2bn79mrb7rgn/T/ecj330314364
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/Users/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/java/org/apache/solr/cloud/api/collections/RestoreCmd.java
(at line 265)
[ecj-lint] throw new SolrException(ErrorCode.BAD_REQUEST, "Unexpected
number of replicas, replicationFactor, " +
[ecj-lint] Replica.Type.NRT + " or " + Replica.Type.TLOG + "
must be greater than 0");
[ecj-lint]
^^^
[ecj-lint] Resource leak: 'repository' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 3. ERROR in
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/java/org/apache/solr/cloud/autoscaling/AutoScalingHandler.java
(at line 74)
[ecj-lint] import static org.apache.solr.common.util.Utils.fromJSON;
[ecj-lint] ^^
[ecj-lint] The import org.apache.solr.common.util.Utils.fromJSON is never used
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 5. WARNING in
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 6. WARNING in
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/java/org/apache/solr/handler/admin/SegmentsInfoRequestHandler.java
(at line 215)
[ecj-lint] leafReader = ((FilterLeafReader)leafReader).getDelegate();
[ecj-lint] ^
[ecj-lint] Resource leak: 'leafReader' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
(at line 142)
[ecj-lint] return new JavaBinCodec(null,
stringCache).setReadStringAsCharSeq(true);
[ecj-lint]^^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 8. WARNING in
/Users/jenkins/workspace/Lucene-Solr-8.x-MacOSX/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java
(at line 137)
[ecj-lint] new JavaBinCodec() {
[ecj-lint] SolrParams params;
[ecj-lint] AddUpdateCommand addCmd = null;
[ecj-lint]
[ecj-lint] @Override
[ecj-lint] public List readIterator(DataInputInputStream fis)
throws IOException {
[ecj-lint] while (true) {
[ecj-lint] Object o = readVal(fis);
[ecj-lint] if (o == END_OBJ) break;
[ecj-lint] if (o instanceof NamedList) {
[ecj-lint] params = ((NamedList) o).toSolrParams();
[ecj-lint] } else {
[ecj-lint] try {
[ecj-lint] if (o instanceof byte[]) {
[ecj-lint]
[jira] [Commented] (SOLR-13467) Spatial: Add S2 lib for more efficient Geo3D indexes
[
https://issues.apache.org/jira/browse/SOLR-13467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840927#comment-16840927
]
ASF subversion and git services commented on SOLR-13467:
Commit 3a88ab616c9c8debe1f3a10e291697083eda3342 in lucene-solr's branch
refs/heads/master from David Wayne Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3a88ab6 ]
SOLR-13467: Include the S2 Geometry lib to make it simpler to use
prefixTree="s2" on a Geo3D spatial field.
* Improved documentation on Geo3D.
* Better testing for Geo3D.
> Spatial: Add S2 lib for more efficient Geo3D indexes
>
>
> Key: SOLR-13467
> URL: https://issues.apache.org/jira/browse/SOLR-13467
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-13467.patch
>
>
> Here I'm adding a dependency on [Google S2 Geometry|http://s2geometry.io]
> (121KB) so that we can use {{prefixTree="s2"}} on a spatial field type that
> is using Geo3D. Lucene spatial-extras already has this dependency, albeit it
> is optional. I enhanced tests to exercise it.
> Additionally, I document here a strictness Geo3D has in which the polygon
> points must be provided in a particular order or else the interpretation of
> the shape is inverted. This so-called "right hand rule" order is somewhat
> standard but some libs (like JTS) don't care.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-8.x-Solaris (64bit/jdk1.8.0) - Build # 129 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Solaris/129/
Java: 64bit/jdk1.8.0 -XX:-UseCompressedOops -XX:+UseSerialGC
All tests passed
Build Log:
[...truncated 62369 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /var/tmp/ecj274454830
[ecj-lint] Compiling 1272 source files to /var/tmp/ecj274454830
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/export/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/export/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/core/src/java/org/apache/solr/cloud/api/collections/RestoreCmd.java
(at line 265)
[ecj-lint] throw new SolrException(ErrorCode.BAD_REQUEST, "Unexpected
number of replicas, replicationFactor, " +
[ecj-lint] Replica.Type.NRT + " or " + Replica.Type.TLOG + "
must be greater than 0");
[ecj-lint]
^^^
[ecj-lint] Resource leak: 'repository' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 3. ERROR in
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/core/src/java/org/apache/solr/cloud/autoscaling/AutoScalingHandler.java
(at line 74)
[ecj-lint] import static org.apache.solr.common.util.Utils.fromJSON;
[ecj-lint] ^^
[ecj-lint] The import org.apache.solr.common.util.Utils.fromJSON is never used
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 5. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 6. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/core/src/java/org/apache/solr/handler/admin/SegmentsInfoRequestHandler.java
(at line 215)
[ecj-lint] leafReader = ((FilterLeafReader)leafReader).getDelegate();
[ecj-lint] ^
[ecj-lint] Resource leak: 'leafReader' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
(at line 142)
[ecj-lint] return new JavaBinCodec(null,
stringCache).setReadStringAsCharSeq(true);
[ecj-lint]^^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 8. WARNING in
/export/home/jenkins/workspace/Lucene-Solr-8.x-Solaris/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java
(at line 137)
[ecj-lint] new JavaBinCodec() {
[ecj-lint] SolrParams params;
[ecj-lint] AddUpdateCommand addCmd = null;
[ecj-lint]
[ecj-lint] @Override
[ecj-lint] public List readIterator(DataInputInputStream fis)
throws IOException {
[ecj-lint] while (true) {
[ecj-lint] Object o = readVal(fis);
[ecj-lint] if (o == END_OBJ) break;
[ecj-lint] if (o instanceof NamedList) {
[ecj-lint] params = ((NamedList) o).toSolrParams();
[ecj-lint] } else {
[ecj-lint] try {
[ecj-lint] if (o instanceof byte[]) {
[ecj-lint] if
[JENKINS] Lucene-Solr-8.x-Linux (64bit/jdk1.8.0_201) - Build # 566 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Linux/566/
Java: 64bit/jdk1.8.0_201 -XX:+UseCompressedOops -XX:+UseParallelGC
All tests passed
Build Log:
[...truncated 62449 lines...]
-ecj-javadoc-lint-src:
[mkdir] Created dir: /tmp/ecj625559328
[ecj-lint] Compiling 1272 source files to /tmp/ecj625559328
[ecj-lint] Processing annotations
[ecj-lint] Annotations processed
[ecj-lint] Processing annotations
[ecj-lint] No elements to process
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet/jars/org.restlet-2.3.0.jar
[ecj-lint] invalid Class-Path header in manifest of jar file:
/home/jenkins/.ivy2/cache/org.restlet.jee/org.restlet.ext.servlet/jars/org.restlet.ext.servlet-2.3.0.jar
[ecj-lint] --
[ecj-lint] 1. WARNING in
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/core/src/java/org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.java
(at line 219)
[ecj-lint] return (NamedList) new
JavaBinCodec(resolver).unmarshal(in);
[ecj-lint]^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 2. WARNING in
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/core/src/java/org/apache/solr/cloud/api/collections/RestoreCmd.java
(at line 265)
[ecj-lint] throw new SolrException(ErrorCode.BAD_REQUEST, "Unexpected
number of replicas, replicationFactor, " +
[ecj-lint] Replica.Type.NRT + " or " + Replica.Type.TLOG + "
must be greater than 0");
[ecj-lint]
^^^
[ecj-lint] Resource leak: 'repository' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 3. ERROR in
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/core/src/java/org/apache/solr/cloud/autoscaling/AutoScalingHandler.java
(at line 74)
[ecj-lint] import static org.apache.solr.common.util.Utils.fromJSON;
[ecj-lint] ^^
[ecj-lint] The import org.apache.solr.common.util.Utils.fromJSON is never used
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 4. WARNING in
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 788)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] 5. WARNING in
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimCloudManager.java
(at line 794)
[ecj-lint] throw new UnsupportedOperationException("must add at least 1
node first");
[ecj-lint]
^^
[ecj-lint] Resource leak: 'queryRequest' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 6. WARNING in
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/core/src/java/org/apache/solr/handler/admin/SegmentsInfoRequestHandler.java
(at line 215)
[ecj-lint] leafReader = ((FilterLeafReader)leafReader).getDelegate();
[ecj-lint] ^
[ecj-lint] Resource leak: 'leafReader' is not closed at this location
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 7. WARNING in
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/core/src/java/org/apache/solr/handler/component/HttpShardHandler.java
(at line 142)
[ecj-lint] return new JavaBinCodec(null,
stringCache).setReadStringAsCharSeq(true);
[ecj-lint]^^^
[ecj-lint] Resource leak: '' is never closed
[ecj-lint] --
[ecj-lint] --
[ecj-lint] 8. WARNING in
/home/jenkins/workspace/Lucene-Solr-8.x-Linux/solr/core/src/java/org/apache/solr/handler/loader/JavabinLoader.java
(at line 137)
[ecj-lint] new JavaBinCodec() {
[ecj-lint] SolrParams params;
[ecj-lint] AddUpdateCommand addCmd = null;
[ecj-lint]
[ecj-lint] @Override
[ecj-lint] public List readIterator(DataInputInputStream fis)
throws IOException {
[ecj-lint] while (true) {
[ecj-lint] Object o = readVal(fis);
[ecj-lint] if (o == END_OBJ) break;
[ecj-lint] if (o instanceof NamedList) {
[ecj-lint] params = ((NamedList) o).toSolrParams();
[ecj-lint] } else {
[ecj-lint] try {
[ecj-lint] if (o instanceof byte[]) {
[ecj-lint] if (params != null) req.setParams(params);
[ecj-lint] byte[] buf = (byte[])
[JENKINS] Solr-reference-guide-8.x - Build # 2980 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2980/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 6a3d32728b784dbba66f6e917d6d277b915d9c72
(refs/remotes/origin/branch_8x)
> git config core.sparsecheckout # timeout=10
> git checkout -f 6a3d32728b784dbba66f6e917d6d277b915d9c72
Commit message: "SOLR-13467: Include the S2 Geometry lib to make it simpler to
use prefixTree="s2" on a Geo3D spatial field. * Improved documentation on
Geo3D. * Better testing for Geo3D."
> git rev-list --no-walk 6a3d32728b784dbba66f6e917d6d277b915d9c72 # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins21473363422200.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using
[jira] [Updated] (SOLR-13474) Fix "Search is temporarily disabled" logic to be consistent for entire request
[
https://issues.apache.org/jira/browse/SOLR-13474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13474:
Issue Type: Bug (was: Improvement)
> Fix "Search is temporarily disabled" logic to be consistent for entire request
> --
>
> Key: SOLR-13474
> URL: https://issues.apache.org/jira/browse/SOLR-13474
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Hoss Man
>Assignee: Hoss Man
>Priority: Major
> Attachments: SOLR-13474.patch
>
>
> Where/How the "Search is temporarily disabled" logic was added in SOLR-12999
> can result in some weird failure cases (examples: SOLR-13470 & SOLR-13471)
> due to the fact that (as currently implemented) some portions of processing
> a SolrQueryRequest may see a valid searcher, but later other code paths will
> get an error when trying to use the same searcher.
> I think it would make more sense to move the "searchEnabled" logic out of
> {{SolrQueryRequestbase.getSearcher()}} and into {{SolrCore.getSearcher()}}
> (removing the need for {{SolrCore.isSearchEnabled()}} ).
> This will:
> * restore the long standing (and widly assumed by code) behavior of
> {{SolrQueryRequestbase.getSearcher()}} that it will always return a
> consistent result
> * ensure that any custom plugins trying to call {{SolrCore.getSearcher()}}
> directly will also get the benefits of the safety checks introduced in
> SOLR-12999
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13470) SolrException msg not always propogated to HttpClient (may be specific to SOLR-12999 ?)
[ https://issues.apache.org/jira/browse/SOLR-13470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16841003#comment-16841003 ] Hoss Man commented on SOLR-13470: - the root cause of the problem appears to be SOLR-13471, triggered by SOLR-13474. > SolrException msg not always propogated to HttpClient (may be specific to > SOLR-12999 ?) > --- > > Key: SOLR-13470 > URL: https://issues.apache.org/jira/browse/SOLR-13470 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Hoss Man >Priority: Major > Attachments: SOLR-13470.patch > > > While working on some test hardening for SOLR-12999, I discovered a strange > bug related to how SolrExceptions are propogated to HttpClients -- sometimes > the message set by the server side code when throwing the SolrException is > set in the remote exception recieved by the HttpSolrClient, other times it is > not. > it's not clear to me if this is specific to the IndexFetcher related code > (added in SOLR-12999) that throw SolrExceptions when the index is in the > middle of a full copy, or if it's a general problem that can happen with any > SolrException->HTTP->RemoteSolrException via HttpSolrClient that only happens > to manifests because of some quirk in the threading of > TestReplicationHandlerDiskOverFlow. > (perhaps because we don't have a lot of HTTP level tests checking the > exception message?) > At the moment, TestReplicationHandlerDiskOverFlow works around this issue by > only comparing the HTTP Staus code to ensure it's what's expected, w/o > checking the getMessage() ... I'll attach a patch that demonstrates how > including a getMessage() assertion can (sporadically) fail, and includes some > nocommit debugging code i added to HttpSolrClient to try and make sense of > what's happening... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-master-Linux (64bit/jdk-11) - Build # 24087 - Failure!
Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/24087/ Java: 64bit/jdk-11 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 2 tests failed. FAILED: org.apache.solr.cloud.ReindexCollectionTest.testReshapeReindexing Error Message: num docs expected:<200> but was:<199> Stack Trace: java.lang.AssertionError: num docs expected:<200> but was:<199> at __randomizedtesting.SeedInfo.seed([A0BB7420EE1C4C78:4BE607194107808D]:0) at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.apache.solr.cloud.ReindexCollectionTest.indexDocs(ReindexCollectionTest.java:393) at org.apache.solr.cloud.ReindexCollectionTest.testReshapeReindexing(ReindexCollectionTest.java:230) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938) at com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974) at com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:947) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:832) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:883) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:894) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:54) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368) at java.base/java.lang.Thread.run(Thread.java:834) FAILED: org.apache.solr.cloud.api.collections.ShardSplitTest.testSplitShardWithRuleLink Error Message: Error from server at
[jira] [Resolved] (SOLR-13467) Spatial: Add S2 lib for more efficient Geo3D indexes
[
https://issues.apache.org/jira/browse/SOLR-13467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-13467.
-
Resolution: Fixed
Fix Version/s: 8.2
> Spatial: Add S2 lib for more efficient Geo3D indexes
>
>
> Key: SOLR-13467
> URL: https://issues.apache.org/jira/browse/SOLR-13467
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.2
>
> Attachments: SOLR-13467.patch
>
>
> Here I'm adding a dependency on [Google S2 Geometry|http://s2geometry.io]
> (121KB) so that we can use {{prefixTree="s2"}} on a spatial field type that
> is using Geo3D. Lucene spatial-extras already has this dependency, albeit it
> is optional. I enhanced tests to exercise it.
> Additionally, I document here a strictness Geo3D has in which the polygon
> points must be provided in a particular order or else the interpretation of
> the shape is inverted. This so-called "right hand rule" order is somewhat
> standard but some libs (like JTS) don't care.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13467) Spatial: Add S2 lib for more efficient Geo3D indexes
[
https://issues.apache.org/jira/browse/SOLR-13467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840928#comment-16840928
]
ASF subversion and git services commented on SOLR-13467:
Commit 6a3d32728b784dbba66f6e917d6d277b915d9c72 in lucene-solr's branch
refs/heads/branch_8x from David Wayne Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=6a3d327 ]
SOLR-13467: Include the S2 Geometry lib to make it simpler to use
prefixTree="s2" on a Geo3D spatial field.
* Improved documentation on Geo3D.
* Better testing for Geo3D.
(cherry picked from commit 3a88ab616c9c8debe1f3a10e291697083eda3342)
> Spatial: Add S2 lib for more efficient Geo3D indexes
>
>
> Key: SOLR-13467
> URL: https://issues.apache.org/jira/browse/SOLR-13467
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation, spatial
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Attachments: SOLR-13467.patch
>
>
> Here I'm adding a dependency on [Google S2 Geometry|http://s2geometry.io]
> (121KB) so that we can use {{prefixTree="s2"}} on a spatial field type that
> is using Geo3D. Lucene spatial-extras already has this dependency, albeit it
> is optional. I enhanced tests to exercise it.
> Additionally, I document here a strictness Geo3D has in which the polygon
> points must be provided in a particular order or else the interpretation of
> the shape is inverted. This so-called "right hand rule" order is somewhat
> standard but some libs (like JTS) don't care.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-SmokeRelease-8.1 - Build # 34 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.1/34/ No tests ran. Build Log: [...truncated 23880 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: ERROR: solr-glossary.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [java] Processed 2531 links (2070 relative) to 3358 anchors in 253 files [echo] Validated Links & Anchors via: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/build/solr-ref-guide/bare-bones-html/ -dist-changes: [copy] Copying 4 files to /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/package/changes package: -unpack-solr-tgz: -ensure-solr-tgz-exists: [mkdir] Created dir: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/build/solr.tgz.unpacked [untar] Expanding: /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/package/solr-8.1.0.tgz into /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/solr/build/solr.tgz.unpacked generate-maven-artifacts: resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/lucene/top-level-ivy-settings.xml resolve: resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.1/lucene/top-level-ivy-settings.xml resolve: ivy-availability-check: [loadresource] Do not set property disallowed.ivy.jars.list as its length is 0. -ivy-fail-disallowed-ivy-version: ivy-fail: ivy-configure: [ivy:configure] :: loading settings ::
[JENKINS] Solr-reference-guide-8.x - Build # 2979 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2979/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 6a3d32728b784dbba66f6e917d6d277b915d9c72
(refs/remotes/origin/branch_8x)
> git config core.sparsecheckout # timeout=10
> git checkout -f 6a3d32728b784dbba66f6e917d6d277b915d9c72
Commit message: "SOLR-13467: Include the S2 Geometry lib to make it simpler to
use prefixTree="s2" on a Geo3D spatial field. * Improved documentation on
Geo3D. * Better testing for Geo3D."
> git rev-list --no-walk 6a3d32728b784dbba66f6e917d6d277b915d9c72 # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins4683260869859788279.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using
[JENKINS] Lucene-Solr-SmokeRelease-8.x - Build # 100 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/100/ No tests ran. Build Log: [...truncated 23882 lines...] [asciidoctor:convert] asciidoctor: ERROR: about-this-guide.adoc: line 1: invalid part, must have at least one section (e.g., chapter, appendix, etc.) [asciidoctor:convert] asciidoctor: WARNING: meta-docs/asciidoc-syntax.adoc: line 67: section title out of sequence: expected level 3, got level 4 [asciidoctor:convert] asciidoctor: WARNING: meta-docs/asciidoc-syntax.adoc: line 75: section title out of sequence: expected level 3, got level 4 [asciidoctor:convert] asciidoctor: WARNING: meta-docs/asciidoc-syntax.adoc: line 117: section title out of sequence: expected level 3, got level 4 [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: filename [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: blobname [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: filename [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: blobname [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: blobname [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: version [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: outputfilename [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: blobname [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: outputfilename [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: blobname [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: version [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: outputfilename [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: blobname [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: outputfilename [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: filename [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: blobname [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: collection [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: collection [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: node_name [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: collection [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: shard [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: replica [asciidoctor:convert] asciidoctor: WARNING: skipping reference to missing attribute: core [java] ID occurs multiple times: v1getcomponent [java] ... file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/config-api.html [java] ... file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/solrcloud-autoscaling-api.html [java] ID occurs multiple times: v2getcomponent [java] ... file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/config-api.html [java] ... file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/solrcloud-autoscaling-api.html [java] Relative link points at id that doesn't exist in dest: solrcloud-autoscaling-api.html#write-api [java] ... source: file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/solrcloud-autoscaling-triggers.html [java] Relative link points at id that doesn't exist in dest: solrcloud-autoscaling-api.html#create-update-trigger [java] ... source: file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/solrcloud-autoscaling-triggers.html [java] Relative link points at id that doesn't exist in dest: solrcloud-autoscaling-api.html#remove-trigger [java] ... source: file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/solrcloud-autoscaling-triggers.html [java] Relative link points at id that doesn't exist in dest: solrcloud-autoscaling-api.html#change-autoscaling-properties [java] ... source: file:/x1/jenkins/jenkins-slave/workspace/Lucene-Solr-SmokeRelease-8.x/solr/build/solr-ref-guide/bare-bones-html/solr-upgrade-notes.html [java] Relative link points at id that doesn't exist in dest: solrcloud-autoscaling-api.html#create-and-modify-cluster-preferences [java] ... source:
[jira] [Created] (LUCENE-8800) FieldsReader#terms poor performance on a index with many fields
Huy Le created LUCENE-8800:
--
Summary: FieldsReader#terms poor performance on a index with many
fields
Key: LUCENE-8800
URL: https://issues.apache.org/jira/browse/LUCENE-8800
Project: Lucene - Core
Issue Type: Improvement
Components: core/codecs
Affects Versions: 8.0
Reporter: Huy Le
Attachments: Screen Shot 2019-05-15 at 5.08.26 pm.png
We have experienced poor performance on an index with many fields, their names
share common prefix. Sampling stack using jprofiler showed a hotspot on method
FieldsReader#terms.
!Screen Shot 2019-05-15 at 5.08.26 pm.png!
Looking at source code I have seen that TreeMap is used to map between field
name to FieldsProducer which means a lookup incurs O(logN) comparisons.
{code:java}
private static class FieldsReader extends FieldsProducer {
...
private final Map fields = new TreeMap<>();
...
@Override
public Terms terms(String field) throws IOException {
FieldsProducer fieldsProducer = fields.get(field);
return fieldsProducer == null ? null : fieldsProducer.terms(field);
}
{code}
The problem becomes much worse when field names are long and share common
prefix because each comparison has to iterate over an entire string.
In our case, the index has around 6000 fields in form of customfield_*. I
wonder if we can change the TreeMap to HashMap or LinkedHashMap in case we want
to preserve the sorted order to improve the situation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-reference-guide-master - Build # 15903 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-master/15903/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 82ede903f64812053ed81ee2e42ed94101e6e091
(refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 82ede903f64812053ed81ee2e42ed94101e6e091
Commit message: "SOLR-13468: added ref-guide"
> git rev-list --no-walk 82ede903f64812053ed81ee2e42ed94101e6e091 # timeout=10
No emails were triggered.
[Solr-reference-guide-master] $ /bin/bash -xe /tmp/jenkins4522411766633743599.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
[jira] [Commented] (SOLR-13437) fork noggit code to Solr
[ https://issues.apache.org/jira/browse/SOLR-13437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840896#comment-16840896 ] ASF subversion and git services commented on SOLR-13437: Commit bd64ed6d2a87b136f68f322e4db413aa37a5eabc in lucene-solr's branch refs/heads/master from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bd64ed6 ] SOLR-13437: fork noggit code into Solr (#666) * SOLR-13437: fork noggit code into Solr > fork noggit code to Solr > > > Key: SOLR-13437 > URL: https://issues.apache.org/jira/browse/SOLR-13437 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > We rely on noggit for all our JSON encoding/decoding needs.The main project > is not actively maintained . We cannot easily switch to another parser > because it may cause backward incompatibility and we have advertised the > ability to use flexible JSON and we also use noggit internally in many classes -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13437) fork noggit code to Solr
[ https://issues.apache.org/jira/browse/SOLR-13437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840895#comment-16840895 ] ASF subversion and git services commented on SOLR-13437: Commit bd64ed6d2a87b136f68f322e4db413aa37a5eabc in lucene-solr's branch refs/heads/master from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=bd64ed6 ] SOLR-13437: fork noggit code into Solr (#666) * SOLR-13437: fork noggit code into Solr > fork noggit code to Solr > > > Key: SOLR-13437 > URL: https://issues.apache.org/jira/browse/SOLR-13437 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > We rely on noggit for all our JSON encoding/decoding needs.The main project > is not actively maintained . We cannot easily switch to another parser > because it may cause backward incompatibility and we have advertised the > ability to use flexible JSON and we also use noggit internally in many classes -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul merged pull request #666: SOLR-13437: fork noggit code into Solr
noblepaul merged pull request #666: SOLR-13437: fork noggit code into Solr URL: https://github.com/apache/lucene-solr/pull/666 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-8800) FieldsReader#terms poor performance on a index with many field names sharing common prefix
[
https://issues.apache.org/jira/browse/LUCENE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved LUCENE-8800.
--
Resolution: Duplicate
Thanks for reporting it but it's a known issue -- LUCENE-8041
> FieldsReader#terms poor performance on a index with many field names sharing
> common prefix
> --
>
> Key: LUCENE-8800
> URL: https://issues.apache.org/jira/browse/LUCENE-8800
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Affects Versions: 8.0
>Reporter: Huy Le
>Priority: Major
> Attachments: Screen Shot 2019-05-15 at 5.08.26 pm.png
>
>
> We have experienced poor performance on an index with many fields, their
> names share common prefix. Sampling stack using jprofiler showed a hotspot on
> method FieldsReader#terms.
> !Screen Shot 2019-05-15 at 5.08.26 pm.png!
> Looking at source code I have seen that TreeMap is used to map between field
> name to FieldsProducer which means a lookup incurs O(logN) comparisons.
> {code:java}
> private static class FieldsReader extends FieldsProducer {
> ...
> private final Map fields = new TreeMap<>();
> ...
> @Override
> public Terms terms(String field) throws IOException {
> FieldsProducer fieldsProducer = fields.get(field);
> return fieldsProducer == null ? null : fieldsProducer.terms(field);
> }
> {code}
> The problem becomes much worse when field names are long and share common
> prefix because each comparison has to iterate over an entire string.
> In our case, the index has around 6000 fields in form of customfield_*. I
> wonder if we can change the TreeMap to HashMap or LinkedHashMap in case we
> want to preserve the sorted order to improve the situation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-8800) FieldsReader#terms poor performance on a index with many field names sharing common prefix
[
https://issues.apache.org/jira/browse/LUCENE-8800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley closed LUCENE-8800.
> FieldsReader#terms poor performance on a index with many field names sharing
> common prefix
> --
>
> Key: LUCENE-8800
> URL: https://issues.apache.org/jira/browse/LUCENE-8800
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs
>Affects Versions: 8.0
>Reporter: Huy Le
>Priority: Major
> Attachments: Screen Shot 2019-05-15 at 5.08.26 pm.png
>
>
> We have experienced poor performance on an index with many fields, their
> names share common prefix. Sampling stack using jprofiler showed a hotspot on
> method FieldsReader#terms.
> !Screen Shot 2019-05-15 at 5.08.26 pm.png!
> Looking at source code I have seen that TreeMap is used to map between field
> name to FieldsProducer which means a lookup incurs O(logN) comparisons.
> {code:java}
> private static class FieldsReader extends FieldsProducer {
> ...
> private final Map fields = new TreeMap<>();
> ...
> @Override
> public Terms terms(String field) throws IOException {
> FieldsProducer fieldsProducer = fields.get(field);
> return fieldsProducer == null ? null : fieldsProducer.terms(field);
> }
> {code}
> The problem becomes much worse when field names are long and share common
> prefix because each comparison has to iterate over an entire string.
> In our case, the index has around 6000 fields in form of customfield_*. I
> wonder if we can change the TreeMap to HashMap or LinkedHashMap in case we
> want to preserve the sorted order to improve the situation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13452) Update the lucene-solr build from Ivy+Ant+Maven (shadow build) to Gradle.
[ https://issues.apache.org/jira/browse/SOLR-13452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840871#comment-16840871 ] Mark Miller commented on SOLR-13452: Cool, that all sounds good to me. I hadn't even seen a buildSrc module before, so however it's supposed to be done sounds good. In terms of compileOnly and stuff, I've only been experimenting, so change away. > 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 > Security Level: Public(Default Security Level. Issues are Public) > Components: Build >Reporter: Mark Miller >Priority: Major > > 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] > By default, dependencies are not transitive, but there is a special > Configuration for adding dependencies on other project internal modules that > are transitive to their direct external dependencies (their jar libs). > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-reference-guide-8.x - Build # 2975 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2975/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 8f9c3e88755dbe95a268e43064d29db3e7d9a49c
(refs/remotes/origin/branch_8x)
> git config core.sparsecheckout # timeout=10
> git checkout -f 8f9c3e88755dbe95a268e43064d29db3e7d9a49c
Commit message: "SOLR-13468: added ref-guide"
> git rev-list --no-walk 8f9c3e88755dbe95a268e43064d29db3e7d9a49c # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins8757770821067627599.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
[JENKINS] Solr-reference-guide-8.x - Build # 2976 - Still Failing
Build: https://builds.apache.org/job/Solr-reference-guide-8.x/2976/
Log:
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on websites1 (git-websites svn-websites) in workspace
/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-8.x
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url
> https://gitbox.apache.org/repos/asf/lucene-solr.git # timeout=10
Cleaning workspace
> git rev-parse --verify HEAD # timeout=10
Resetting working tree
> git reset --hard # timeout=10
> git clean -fdx # timeout=10
Fetching upstream changes from
https://gitbox.apache.org/repos/asf/lucene-solr.git
> git --version # timeout=10
> git fetch --tags --progress
> https://gitbox.apache.org/repos/asf/lucene-solr.git
> +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/branch_8x^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/branch_8x^{commit} # timeout=10
Checking out Revision 8f9c3e88755dbe95a268e43064d29db3e7d9a49c
(refs/remotes/origin/branch_8x)
> git config core.sparsecheckout # timeout=10
> git checkout -f 8f9c3e88755dbe95a268e43064d29db3e7d9a49c
Commit message: "SOLR-13468: added ref-guide"
> git rev-list --no-walk 8f9c3e88755dbe95a268e43064d29db3e7d9a49c # timeout=10
No emails were triggered.
[Solr-reference-guide-8.x] $ /bin/bash -xe /tmp/jenkins1333682127631505075.sh
+ bash dev-tools/scripts/jenkins.build.ref.guide.sh
+ set -e
+ RVM_PATH=/home/jenkins/.rvm
+ RUBY_VERSION=ruby-2.3.3
+ GEMSET=solr-refguide-gemset
+ curl -sSL https://get.rvm.io
+ bash -s -- --ignore-dotfiles stable
Turning on ignore dotfiles mode.
Downloading https://github.com/rvm/rvm/archive/1.29.8.tar.gz
Downloading
https://github.com/rvm/rvm/releases/download/1.29.8/1.29.8.tar.gz.asc
gpg: Signature made Wed 08 May 2019 02:14:49 PM UTC using RSA key ID 39499BDB
gpg: Good signature from "Piotr Kuczynski "
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7D2B AF1C F37B 13E2 069D 6956 105B D0E7 3949 9BDB
GPG verified '/home/jenkins/shared/.rvm/archives/rvm-1.29.8.tgz'
Upgrading the RVM installation in /home/jenkins/shared/.rvm/
Upgrade of RVM in /home/jenkins/shared/.rvm/ is complete.
* It looks like some old stuff is laying around RVM, you can cleanup with:
rvm cleanup all
Thanks for installing RVM
Please consider donating to our open collective to help us maintain RVM.
Donate: https://opencollective.com/rvm/donate
+ set +x
Running 'source /home/jenkins/.rvm/scripts/rvm'
Running 'rvm cleanup all'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Cleaning up rvm archives
Cleaning up rvm repos
Cleaning up rvm src
Cleaning up rvm log
Cleaning up rvm tmp
Cleaning up rvm gemsets
Cleaning up rvm links
Cleanup done.
Running 'rvm autolibs disable'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Running 'rvm install ruby-2.3.3'
Warning! PATH is not properly set up,
/home/jenkins/shared/.rvm/gems/ruby-2.3.3/bin is not at first place.
Usually this is caused by shell initialization files. Search for
PATH=... entries.
You can also re-add RVM to your profile by running: rvm get
stable --auto-dotfiles
To fix it temporarily in this shell session run: rvm use
ruby-2.3.3
To ignore this error add
rvm_silence_path_mismatch_check_flag=1 to your
~/.rvmrc file.
Already installed ruby-2.3.3.
To reinstall use:
rvm reinstall ruby-2.3.3
Running 'rvm gemset create solr-refguide-gemset'
ruby-2.3.3 - #gemset created
/home/jenkins/shared/.rvm/gems/ruby-2.3.3@solr-refguide-gemset
[32mruby-2.3.3 - #generating solr-refguide-gemset
wrappers[0m|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\|.-\|/-\|/-.|/-\|/-\.
Running 'rvm ruby-2.3.3@solr-refguide-gemset'
Using /home/jenkins/shared/.rvm/gems/ruby-2.3.3 with gemset solr-refguide-gemset
Running 'gem install --force --version 3.5.0 jekyll'
Successfully installed jekyll-3.5.0
[jira] [Commented] (SOLR-13437) fork noggit code to Solr
[ https://issues.apache.org/jira/browse/SOLR-13437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840924#comment-16840924 ] ASF subversion and git services commented on SOLR-13437: Commit 0f67df40b6916aab076ca1b2312e85547ac5693d in lucene-solr's branch refs/heads/branch_8x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0f67df4 ] SOLR-13437: fork noggit code into Solr (#666) * SOLR-13437: fork noggit code into Solr > fork noggit code to Solr > > > Key: SOLR-13437 > URL: https://issues.apache.org/jira/browse/SOLR-13437 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > We rely on noggit for all our JSON encoding/decoding needs.The main project > is not actively maintained . We cannot easily switch to another parser > because it may cause backward incompatibility and we have advertised the > ability to use flexible JSON and we also use noggit internally in many classes -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13437) fork noggit code to Solr
[ https://issues.apache.org/jira/browse/SOLR-13437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16840923#comment-16840923 ] ASF subversion and git services commented on SOLR-13437: Commit 0f67df40b6916aab076ca1b2312e85547ac5693d in lucene-solr's branch refs/heads/branch_8x from Noble Paul [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0f67df4 ] SOLR-13437: fork noggit code into Solr (#666) * SOLR-13437: fork noggit code into Solr > fork noggit code to Solr > > > Key: SOLR-13437 > URL: https://issues.apache.org/jira/browse/SOLR-13437 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrJ >Reporter: Noble Paul >Assignee: Noble Paul >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > We rely on noggit for all our JSON encoding/decoding needs.The main project > is not actively maintained . We cannot easily switch to another parser > because it may cause backward incompatibility and we have advertised the > ability to use flexible JSON and we also use noggit internally in many classes -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr 8.1 issue with collection aliases
Sorry autocorrection. It is not only a admin UI issue. I described in my
previous email that access through the collection alias does not work. I cannot
even do execute the select query handler if I use the collection alias instead
of the collection name.
So it is maybe more problematic.
> Am 16.05.2019 um 04:36 schrieb Jörn Franke :
>
> Note only an admin UI issue. Access collections via their alias does not work.
>
>> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
>>
>> It seems creating alias in Solr Admin UI is broken. It's a minor issue for
>> 8.1.0
>> I've alias via REST call
>> http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
>> successfully.
>> Jörn, thanks for reporting.
>>
>>> On Tue, May 14, 2019 at 11:03 PM Jörn Franke wrote:
>>> Hi,
>>>
>>> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with
>>> collection aliases, but I am not 100% sure it is due to the upgrade.
>>>
>>> Situation:
>>> I have a collection called c_testcollection.
>>> I have an alias called testcollection.
>>> Alias "testcollection" points to "c_testcollection".
>>> On Solr 8.0 no issue
>>>
>>> After upgrade to Solr 8.1:
>>> When I do a query on c_testcollection then there is no issue:
>>> http://localhost:8983/solr/c_testcollection/select?q=test
>>> When I do a query on testcollection then I receive the stacktrace below
>>> http://localhost:8983/solr/testcollection/select?q=test
>>>
>>> Additionally I observe a strange behavior in the admin ui. When I try to
>>> create an alias (e.g. new) for a new collection (e.g. c_new) then it
>>> creates two aliases:
>>> new => c_new
>>> c_new => c_new
>>> if i then do a query on the alias new it works without issues. If I remove
>>> the alias from c_new to c_new then I get the same error. Is this desired
>>> behaviour?
>>> It is rather annoying to have unnecessary aliases, because I need to filter
>>> them out in my application when retrieving all aliases.
>>> Is there a related issue.
>>>
>>> Here the stacktrace:
>>> {
>>> "error":{
>>> "trace":"java.lang.NullPointerException\n\tat
>>> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>>> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>>> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
>>> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>>> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
>>> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
>>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\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:1588)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>>> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>>> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\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:502)\n\tat
>>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>> org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333)\n\tat
>>>
Re: Solr 8.1 issue with collection aliases
Please open a JIRA.
On Thu, 16 May, 2019, 8:09 AM Jörn Franke, wrote:
> Sorry autocorrection. It is not only a admin UI issue. I described in my
> previous email that access through the collection alias does not work. I
> cannot even do execute the select query handler if I use the collection
> alias instead of the collection name.
> So it is maybe more problematic.
>
> Am 16.05.2019 um 04:36 schrieb Jörn Franke :
>
> Note only an admin UI issue. Access collections via their alias does not
> work.
>
> Am 15.05.2019 um 15:47 schrieb Mikhail Khludnev :
>
> It seems creating alias in Solr Admin UI is broken. It's a minor issue for
> 8.1.0
> I've alias via REST call
> http://localhost:8983/solr/admin/collections?action=CREATEALIAS=testalias=gettingstarted
> successfully.
> Jörn, thanks for reporting.
>
> On Tue, May 14, 2019 at 11:03 PM Jörn Franke wrote:
>
>> Hi,
>>
>> I tried to upgrade from 8.0 to 8.1. I noticed that there is an issue with
>> collection aliases, but I am not 100% sure it is due to the upgrade.
>>
>> Situation:
>> I have a collection called c_testcollection.
>> I have an alias called testcollection.
>> Alias "testcollection" points to "c_testcollection".
>> On Solr 8.0 no issue
>>
>> After upgrade to Solr 8.1:
>> When I do a query on c_testcollection then there is no issue:
>> http://localhost:8983/solr/c_testcollection/select?q=test
>> When I do a query on testcollection then I receive the stacktrace below
>> http://localhost:8983/solr/testcollection/select?q=test
>>
>> Additionally I observe a strange behavior in the admin ui. When I try to
>> create an alias (e.g. new) for a new collection (e.g. c_new) then it
>> creates two aliases:
>> new => c_new
>> c_new => c_new
>> if i then do a query on the alias new it works without issues. If I remove
>> the alias from c_new to c_new then I get the same error. Is this desired
>> behaviour?
>> It is rather annoying to have unnecessary aliases, because I need to
>> filter
>> them out in my application when retrieving all aliases.
>> Is there a related issue.
>>
>> Here the stacktrace:
>> {
>> "error":{
>> "trace":"java.lang.NullPointerException\n\tat
>>
>> java.base/java.util.AbstractCollection.addAll(AbstractCollection.java:351)\n\tat
>>
>> org.apache.solr.common.cloud.Aliases.resolveAliasesGivenAliasMap(Aliases.java:258)\n\tat
>>
>> org.apache.solr.common.cloud.Aliases.resolveAliases(Aliases.java:181)\n\tat
>>
>> org.apache.solr.servlet.HttpSolrCall.resolveCollectionListOrAlias(HttpSolrCall.java:385)\n\tat
>> org.apache.solr.servlet.HttpSolrCall.init(HttpSolrCall.java:273)\n\tat
>> org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:486)\n\tat
>>
>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:397)\n\tat
>>
>> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)\n\tat
>>
>> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602)\n\tat
>>
>> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540)\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:1588)\n\tat
>>
>> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255)\n\tat
>>
>> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1345)\n\tat
>>
>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203)\n\tat
>>
>> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480)\n\tat
>>
>> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1557)\n\tat
>>
>> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201)\n\tat
>>
>> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1247)\n\tat
>>
>> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144)\n\tat
>>
>> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220)\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:502)\n\tat
>> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:364)\n\tat
>> org.eclipse.jetty.server.HttpChannel.run(HttpChannel.java:305)\n\tat
>>
>>
