[GitHub] [lucene-solr] mocobeta commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
mocobeta commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r426972295
##
File path: gradle/validation/check-broken-links.gradle
##
@@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+configure(rootProject) {
+
+ task checkBrokenLinks {
+group 'Verification'
+description 'Check broken links in the entire documentation'
+
+dependsOn ':lucene:checkBrokenLinks'
+dependsOn ':solr:checkBrokenLinks'
+ }
+
+}
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+
+ task checkBrokenLinks(type: CheckBrokenLinksTask, 'dependsOn':
'documentation')
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn checkBrokenLinks
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+
+ @Input
Review comment:
I replaced it with `@InputDirectory` (since `@InputFile` does not work
for me.)
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
mocobeta commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r426971028
##
File path: gradle/validation/check-broken-links.gradle
##
@@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+configure(rootProject) {
+
+ task checkBrokenLinks {
+group 'Verification'
+description 'Check broken links in the entire documentation'
+
+dependsOn ':lucene:checkBrokenLinks'
+dependsOn ':solr:checkBrokenLinks'
+ }
+
+}
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+
+ task checkBrokenLinks(type: CheckBrokenLinksTask, 'dependsOn':
'documentation')
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn checkBrokenLinks
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+
+ @Input
+ Provider docsDir = project.providers.provider { project.docroot }
+
+ @Input
Review comment:
Fixed.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12823) remove clusterstate.json in Lucene/Solr 8.0
[
https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110696#comment-17110696
]
Ilan Ginzburg commented on SOLR-12823:
--
[~noble.paul] is there a Jira for porting the Admin UI to use
{{ZookeeperReadAPI}}?
> remove clusterstate.json in Lucene/Solr 8.0
> ---
>
> Key: SOLR-12823
> URL: https://issues.apache.org/jira/browse/SOLR-12823
> Project: Solr
> Issue Type: Task
>Reporter: Varun Thacker
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove
> that in 8.0
> It stays empty unless you explicitly ask to create the collection with the
> old "stateFormat" and there is no reason for one to create a collection with
> the old stateFormat.
> We should also remove the "stateFormat" argument in create collection
> We should also remove MIGRATESTATEVERSION as well
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12823) remove clusterstate.json in Lucene/Solr 8.0
[
https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110695#comment-17110695
]
Ilan Ginzburg commented on SOLR-12823:
--
I’m sharing a work in progress (draft) Pull Request, but almost done:
[https://github.com/apache/lucene-solr/pull/1528]
I believe “production” code is complete, but:
* {{org.apache.solr.cloud.autoscaling.sim}} assumes stateFormat 1 and the
presence of {{/clusterstate.json}}. I didn’t look into what changes are
required there. Some code got commented out in order to compile, tests are
failing.
* {{TestZkChroot}} breaks. That test needs to be written differently, possibly
by starting a local SolrCloud with a non hard coded chroot (rather than
{{/solr}}).
* {{BasicZkTest}} fails as well. I’d like to remove it unless somebody thinks
it has value.
This PR removes all code dealing with {{/clusterstate.json}} in Zookeeper. It
also removes {{MIGRATESTATEVERSION}} Collection API action and the notion of
“legacyCloud” (legacyCloud mode no longer supported).
Fun fact: all OverseerTest collections were created in stateFormat 1.
I’d like to start getting feedback on these changes. Will look in the meantime
at changes required in the autoscaling sim code (SOLR-14486), unless you want
to do that [~ab] ?
Any comments or guidance on how to continue from here are most welcome. This is
one of my first PR’s on lucene-solr (actually the second given SOLR-14473 was
merged three hours ago, thanks [~mdrob]!).
> remove clusterstate.json in Lucene/Solr 8.0
> ---
>
> Key: SOLR-12823
> URL: https://issues.apache.org/jira/browse/SOLR-12823
> Project: Solr
> Issue Type: Task
>Reporter: Varun Thacker
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove
> that in 8.0
> It stays empty unless you explicitly ask to create the collection with the
> old "stateFormat" and there is no reason for one to create a collection with
> the old stateFormat.
> We should also remove the "stateFormat" argument in create collection
> We should also remove MIGRATESTATEVERSION as well
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12823) remove clusterstate.json in Lucene/Solr 8.0
[
https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110694#comment-17110694
]
Noble Paul commented on SOLR-12823:
---
[~murblanc] It's reverted but put back as \{{ZookeeperReadAPI}}. I would
recommend using that API instead of the unsupported {{/admin/zookeeper}}
> remove clusterstate.json in Lucene/Solr 8.0
> ---
>
> Key: SOLR-12823
> URL: https://issues.apache.org/jira/browse/SOLR-12823
> Project: Solr
> Issue Type: Task
>Reporter: Varun Thacker
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove
> that in 8.0
> It stays empty unless you explicitly ask to create the collection with the
> old "stateFormat" and there is no reason for one to create a collection with
> the old stateFormat.
> We should also remove the "stateFormat" argument in create collection
> We should also remove MIGRATESTATEVERSION as well
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc opened a new pull request #1528: SOLR-12823: remove /clusterstate.json
murblanc opened a new pull request #1528: URL: https://github.com/apache/lucene-solr/pull/1528 Remove all code dealing with Zookeeper's /clusterstate.json, remove Collection API's MIGRATESTATEVERSION, remove legacyCloud option. Notes: - org.apache.solr.cloud.autoscaling.sim is non functional, requires more work. - TestZkChroot requires more work - BasicZkTest requires more work (or better: be deleted) Also fixes SOLR-11877: DocCollection.getStateFormat is buggy # Description Remove all code dealing with /clusterstate.json in Zookeeper, remove MIGRATESTATEVERSION Collection API action and the notion of “legacyCloud”. Note this is a draft PR at this stage, need to fix the autoscale sim before it can be merged. # Solution Solr 9 will refuse to start if an existing /clusterstate.json in Zookeeper exists and is not empty. # Tests No new tests, but adapting old tests that were misbehaving. # Checklist Please review the following and check all that apply: - [X] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [X] I have created a Jira issue and added the issue ID to my pull request title. - [X] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [X] I have developed this patch against the `master` branch. - [X] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [X] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14472) Autoscaling "cores" preference should count all cores, not just loaded.
[
https://issues.apache.org/jira/browse/SOLR-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-14472.
-
Fix Version/s: 8.6
Resolution: Fixed
> Autoscaling "cores" preference should count all cores, not just loaded.
> ---
>
> Key: SOLR-14472
> URL: https://issues.apache.org/jira/browse/SOLR-14472
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Fix For: 8.6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The AutoScaling "cores" preference works by counting the core names that are
> retrievable via the metrics API. 99% of the time, that's fine but it does
> not count unloaded transient cores that are also tracked by the
> CoreContainer, which I think should be counted as well. Most users don't
> have such cores so it won't affect them.
> Furthermore, instead of counting them by asking the metrics API to return
> each loaded core name, it should use the {{CONTAINER.cores}} prefix set of
> counters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14472) Autoscaling "cores" preference should count all cores, not just loaded.
[
https://issues.apache.org/jira/browse/SOLR-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110646#comment-17110646
]
ASF subversion and git services commented on SOLR-14472:
Commit 253f04cef89e3a0961cff2c1d8de44eebcb893b4 in lucene-solr's branch
refs/heads/branch_8x from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=253f04c ]
SOLR-14472: Autoscale "cores": use metrics to count
Also counts all cores (lazy, transient), although currently impossible to use
these in SolrCloud.
(cherry picked from commit d3d0df9da15b9a60280775a0deb4f57e1bd3dea5)
> Autoscaling "cores" preference should count all cores, not just loaded.
> ---
>
> Key: SOLR-14472
> URL: https://issues.apache.org/jira/browse/SOLR-14472
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The AutoScaling "cores" preference works by counting the core names that are
> retrievable via the metrics API. 99% of the time, that's fine but it does
> not count unloaded transient cores that are also tracked by the
> CoreContainer, which I think should be counted as well. Most users don't
> have such cores so it won't affect them.
> Furthermore, instead of counting them by asking the metrics API to return
> each loaded core name, it should use the {{CONTAINER.cores}} prefix set of
> counters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14472) Autoscaling "cores" preference should count all cores, not just loaded.
[
https://issues.apache.org/jira/browse/SOLR-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110642#comment-17110642
]
ASF subversion and git services commented on SOLR-14472:
Commit 9259f00748de2d056850526a85f144ae07f70ed3 in lucene-solr's branch
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9259f00 ]
SOLR-14472: missed CHANGES.txt
> Autoscaling "cores" preference should count all cores, not just loaded.
> ---
>
> Key: SOLR-14472
> URL: https://issues.apache.org/jira/browse/SOLR-14472
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The AutoScaling "cores" preference works by counting the core names that are
> retrievable via the metrics API. 99% of the time, that's fine but it does
> not count unloaded transient cores that are also tracked by the
> CoreContainer, which I think should be counted as well. Most users don't
> have such cores so it won't affect them.
> Furthermore, instead of counting them by asking the metrics API to return
> each loaded core name, it should use the {{CONTAINER.cores}} prefix set of
> counters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley closed pull request #1508: SOLR-14472: AutoScale: "cores" also track lazy, transient
dsmiley closed pull request #1508: URL: https://github.com/apache/lucene-solr/pull/1508 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on pull request #1508: SOLR-14472: AutoScale: "cores" also track lazy, transient
dsmiley commented on pull request #1508: URL: https://github.com/apache/lucene-solr/pull/1508#issuecomment-630450887 Merged d3d0df9da15b9a60280775a0deb4f57e1bd3dea5 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14472) Autoscaling "cores" preference should count all cores, not just loaded.
[
https://issues.apache.org/jira/browse/SOLR-14472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110641#comment-17110641
]
ASF subversion and git services commented on SOLR-14472:
Commit d3d0df9da15b9a60280775a0deb4f57e1bd3dea5 in lucene-solr's branch
refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d3d0df9 ]
SOLR-14472: Autoscale "cores": use metrics to count
Also counts all cores (lazy, transient), although currently impossible to use
these in SolrCloud.
> Autoscaling "cores" preference should count all cores, not just loaded.
> ---
>
> Key: SOLR-14472
> URL: https://issues.apache.org/jira/browse/SOLR-14472
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: AutoScaling
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>
> The AutoScaling "cores" preference works by counting the core names that are
> retrievable via the metrics API. 99% of the time, that's fine but it does
> not count unloaded transient cores that are also tracked by the
> CoreContainer, which I think should be counted as well. Most users don't
> have such cores so it won't affect them.
> Furthermore, instead of counting them by asking the metrics API to return
> each loaded core name, it should use the {{CONTAINER.cores}} prefix set of
> counters.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7788) fail precommit on unparameterised log messages and examine for wasted work/objects
[
https://issues.apache.org/jira/browse/LUCENE-7788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110634#comment-17110634
]
David Smiley commented on LUCENE-7788:
--
There were lines like this that didn't have the surrounding isXXXEnabled check
until you added them:
{code:java}
log.info("Error on getting remote info, trying again: {}",
e.getMessage());
{code}
Where {{e}} is an Exception. I often see this and argue this should be
avoided, as it's better to simply supply "e" here because the toString on an
Exception has more information which can be semantically meaningful. An
example is a FileNotFoundException, where the message is merely the name of the
file but lacks what the problem was. Now there's a new reason to do this -- no
wrapping of isInfoEnabled :-)
> fail precommit on unparameterised log messages and examine for wasted
> work/objects
> --
>
> Key: LUCENE-7788
> URL: https://issues.apache.org/jira/browse/LUCENE-7788
> Project: Lucene - Core
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 8.6
>
> Attachments: LUCENE-7788.patch, LUCENE-7788.patch, gradle_only.patch,
> gradle_only.patch
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> SOLR-10415 would be removing existing unparameterised log.trace messages use
> and once that is in place then this ticket's one-line change would be for
> 'ant precommit' to reject any future unparameterised log.trace message use.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14384) Stack SolrRequestInfo
[ https://issues.apache.org/jira/browse/SOLR-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110598#comment-17110598 ] Nazerke Seidan edited comment on SOLR-14384 at 5/18/20, 8:42 PM: - Hello [~mkhl], I have made a PR to this issue, could you have a look? With [~dsmiley]'s help I have refactored the code. was (Author: seidan): Hello [~mkhl], I have made a PR to this issue, could you have a look? With [~dsmiley]'s help I refactored the code. > Stack SolrRequestInfo > - > > Key: SOLR-14384 > URL: https://issues.apache.org/jira/browse/SOLR-14384 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Sometimes SolrRequestInfo need to be suspended or overridden. [~dsmiley] > suggests to introduce stacking for it. See linked issues for the context and > discussion. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14384) Stack SolrRequestInfo
[ https://issues.apache.org/jira/browse/SOLR-14384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110598#comment-17110598 ] Nazerke Seidan commented on SOLR-14384: --- Hello [~mkhl], I have made a PR to this issue, could you have a look? With [~dsmiley]'s help I refactored the code. > Stack SolrRequestInfo > - > > Key: SOLR-14384 > URL: https://issues.apache.org/jira/browse/SOLR-14384 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mikhail Khludnev >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Sometimes SolrRequestInfo need to be suspended or overridden. [~dsmiley] > suggests to introduce stacking for it. See linked issues for the context and > discussion. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] NazerkeBS opened a new pull request #1527: SOLR-14384 Stack SolrRequestInfo
NazerkeBS opened a new pull request #1527: URL: https://github.com/apache/lucene-solr/pull/1527 # Description Please provide a short description of the changes you're making with this pull request. # Solution Please provide a short description of the approach taken to implement your solution. # Tests Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `ant precommit` and the appropriate test suite. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12823) remove clusterstate.json in Lucene/Solr 8.0
[ https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110592#comment-17110592 ] Ilan Ginzburg commented on SOLR-12823: -- [~dsmiley] SOLR-13942 might have been reverted since, I don't see ZkRead.java on master. Also, it did not provide the same service as /admin/zookeeper that's used by the Admin UI. It implemented a recursive dump of the ZK tree below a path. /admin/zookeeper returns what's needed to display the collection list + config and supports filtering and paging. > remove clusterstate.json in Lucene/Solr 8.0 > --- > > Key: SOLR-12823 > URL: https://issues.apache.org/jira/browse/SOLR-12823 > Project: Solr > Issue Type: Task >Reporter: Varun Thacker >Priority: Major > > clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove > that in 8.0 > It stays empty unless you explicitly ask to create the collection with the > old "stateFormat" and there is no reason for one to create a collection with > the old stateFormat. > We should also remove the "stateFormat" argument in create collection > We should also remove MIGRATESTATEVERSION as well > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-14473) Improve Overseer Javadoc
[ https://issues.apache.org/jira/browse/SOLR-14473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob resolved SOLR-14473. -- Fix Version/s: master (9.0) Assignee: Mike Drob Resolution: Fixed Thanks for the updated docs, [~murblanc]! Looking forward to more! > Improve Overseer Javadoc > > > Key: SOLR-14473 > URL: https://issues.apache.org/jira/browse/SOLR-14473 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (9.0) >Reporter: Ilan Ginzburg >Assignee: Mike Drob >Priority: Minor > Labels: documentation > Fix For: master (9.0) > > Time Spent: 50m > Remaining Estimate: 0h > > Improve the Overseer Javadoc (Jira motivated in part by doc > [https://docs.google.com/document/d/1KTHq3noZBVUQ7QNuBGEhujZ_duwTVpAsvN3Nz5anQUY/edit#]) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14473) Improve Overseer Javadoc
[ https://issues.apache.org/jira/browse/SOLR-14473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110590#comment-17110590 ] ASF subversion and git services commented on SOLR-14473: Commit d2825282c984a7eca102d74f16c28eed5a4dda92 in lucene-solr's branch refs/heads/master from murblanc [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d282528 ] SOLR-14473: Improve Overseer Javadoc (#1510) Co-authored-by: Ilan Ginzburg > Improve Overseer Javadoc > > > Key: SOLR-14473 > URL: https://issues.apache.org/jira/browse/SOLR-14473 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud >Affects Versions: master (9.0) >Reporter: Ilan Ginzburg >Priority: Minor > Labels: documentation > Time Spent: 40m > Remaining Estimate: 0h > > Improve the Overseer Javadoc (Jira motivated in part by doc > [https://docs.google.com/document/d/1KTHq3noZBVUQ7QNuBGEhujZ_duwTVpAsvN3Nz5anQUY/edit#]) -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] madrob merged pull request #1510: SOLR-14473: Improve Overseer Javadoc
madrob merged pull request #1510: URL: https://github.com/apache/lucene-solr/pull/1510 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (LUCENE-9074) Account for Executor's Queue Length When Planning Slices in IndexSearcher
[ https://issues.apache.org/jira/browse/LUCENE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated LUCENE-9074: - Fix Version/s: master (9.0) > Account for Executor's Queue Length When Planning Slices in IndexSearcher > - > > Key: LUCENE-9074 > URL: https://issues.apache.org/jira/browse/LUCENE-9074 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Fix For: master (9.0) > > Time Spent: 10h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14476) Add percentiles and standard deviation aggregations to stats, facet and timeseries Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-14476:
--
Attachment: SOLR-14476.patch
> Add percentiles and standard deviation aggregations to stats, facet and
> timeseries Streaming Expressions
>
>
> Key: SOLR-14476
> URL: https://issues.apache.org/jira/browse/SOLR-14476
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch,
> SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch,
> SOLR-14476.patch
>
>
> This ticket will add the *per* (percentile) and *std* (standard deviation)
> aggregations to the *stats*, *facet* and *timeseries* Streaming Expressions.
> Syntax:
>
> {code:java}
> facet(logs, buckets="collection_s", per(qtime_i, 50), std(qtime_i)) {code}
> The stats function will also be reimplemented using JSON facets rather than
> the stats component as part of this ticket. The main reason is that JSON
> facets syntax is easier to work with for percentiles, but it also
> standardized are pushed down aggregations to JSON facets.
> In a separate ticket *per* and *std* aggregations will be added to the
> *rollup*, *hashRollup* and *nodes* Streaming Expressions.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14142) Enable jetty's request log by default
[
https://issues.apache.org/jira/browse/SOLR-14142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110559#comment-17110559
]
David Smiley commented on SOLR-14142:
-
I'm +1 but my only concern is the default retention period.
{{solr/server/etc/jetty-requestlog.xml:33}} shows a whopping 90 days. There's
no size constraint. Since these logs are partially redundant with Solr's own
logging, I propose we dial this down to 7 days. WDYT?
> Enable jetty's request log by default
> -
>
> Key: SOLR-14142
> URL: https://issues.apache.org/jira/browse/SOLR-14142
> Project: Solr
> Issue Type: Improvement
>Reporter: Robert Muir
>Priority: Major
> Fix For: master (9.0)
>
> Attachments: SOLR-14142.patch, SOLR-14142.patch
>
>
> I'd like to enable the jetty request log by default.
> This log is now in the correct directory, it no longer uses the deprecated
> mechanisms (it is asynclogwriter + customformat), etc. See SOLR-14138.
> This log is in a standard format (NCSA) which is supported by tools
> out-of-box. It does not contain challenges such as java exceptions and is
> easy to work with. Without it enabled, solr really has insufficient logging
> (e.g. no IP addresses).
> If someone's solr gets hacked, its only fair they at least get to see who did
> it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley merged pull request #1430: SOLR-13101: SHARED replica's distributed indexing
dsmiley merged pull request #1430: URL: https://github.com/apache/lucene-solr/pull/1430 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13101) Shared storage support in SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110552#comment-17110552 ] ASF subversion and git services commented on SOLR-13101: Commit ad3f0a30181aa4d7ba099ee67fd45fa98cf9c2c0 in lucene-solr's branch refs/heads/jira/SOLR-13101 from Bilal Waheed [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ad3f0a3 ] SOLR-13101: SHARED replica's distributed indexing (#1430) * SOLR-13101: SHARED replica's distributed indexing The basic purpose of this change was to refactor most of the SHARED replica logic out of DistributedZkUpdateProcessor. Along with that refactoring I came across couple of functional issues in the logic that have been fixed too. Functional fixes: -If a replica looses its leadership in the middle of indexing batch, it should still push its changes to the shared store. -SHARED replica does not need to process soft commits and does not need to broadcast hard commits to all the shards of a collection. -Previously we would pull from the shared store even when the doc being added/deleted is not meant for the current core/shard. -Previously DistributedZkUpdateProcessor#processDelete was running its pull logic even before the request had been setup (DistributedZkUpdateProcessor#setupRequest). -DistributedZkUpdateProcessorTest have been deleted in favor of new SharedStoreDistributedIndexingTest SharedCoreIndexingBatchProcessorTest. Refactoring: -Most of DistributedZkUpdateProcessor's SHARED replica logic is moved into a new SharedCoreIndexingBatchProcessor. The purpose of this class is to pull from the shared store at the start of an indexing batch (if the core is stale) and push to the shared store at the end of a successfully committed indexing batch. -CoreUpdateTracker has been deleted and its only persistShardIndexToSharedStore method has been renamed to pushCoreToSharedStore and moved to CorePusher. -BlobStoreUtilsTest#syncLocalCoreWithSharedStore is renamed to pullCoreFromSharedStore and moved into a new CorePuller class and the tests to CorePullerTests. -I did rename phrase "blob store" to "shared store" at some places in the changed classes. But it was not meant to be an exhaustive attempt. * -Throw error for pull request for an unknown. -Log warning when indexing a non-active shard. * Address CR feedback. > Shared storage support in SolrCloud > --- > > Key: SOLR-13101 > URL: https://issues.apache.org/jira/browse/SOLR-13101 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Yonik Seeley >Priority: Major > Time Spent: 15h 40m > Remaining Estimate: 0h > > Solr should have first-class support for shared storage (blob/object stores > like S3, google cloud storage, etc. and shared filesystems like HDFS, NFS, > etc). > The key component will likely be a new replica type for shared storage. It > would have many of the benefits of the current "pull" replicas (not indexing > on all replicas, all shards identical with no shards getting out-of-sync, > etc), but would have additional benefits: > - Any shard could become leader (the blob store always has the index) > - Better elasticity scaling down >- durability not linked to number of replcias.. a single replica could be > common for write workloads >- could drop to 0 replicas for a shard when not needed (blob store always > has index) > - Allow for higher performance write workloads by skipping the transaction > log >- don't pay for what you don't need >- a commit will be necessary to flush to stable storage (blob store) > - A lot of the complexity and failure modes go away > An additional component a Directory implementation that will work well with > blob stores. We probably want one that treats local disk as a cache since > the latency to remote storage is so large. I think there are still some > "locking" issues to be solved here (ensuring that more than one writer to the > same index won't corrupt it). This should probably be pulled out into a > different JIRA issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13101) Shared storage support in SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110553#comment-17110553 ] ASF subversion and git services commented on SOLR-13101: Commit ad3f0a30181aa4d7ba099ee67fd45fa98cf9c2c0 in lucene-solr's branch refs/heads/jira/SOLR-13101 from Bilal Waheed [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ad3f0a3 ] SOLR-13101: SHARED replica's distributed indexing (#1430) * SOLR-13101: SHARED replica's distributed indexing The basic purpose of this change was to refactor most of the SHARED replica logic out of DistributedZkUpdateProcessor. Along with that refactoring I came across couple of functional issues in the logic that have been fixed too. Functional fixes: -If a replica looses its leadership in the middle of indexing batch, it should still push its changes to the shared store. -SHARED replica does not need to process soft commits and does not need to broadcast hard commits to all the shards of a collection. -Previously we would pull from the shared store even when the doc being added/deleted is not meant for the current core/shard. -Previously DistributedZkUpdateProcessor#processDelete was running its pull logic even before the request had been setup (DistributedZkUpdateProcessor#setupRequest). -DistributedZkUpdateProcessorTest have been deleted in favor of new SharedStoreDistributedIndexingTest SharedCoreIndexingBatchProcessorTest. Refactoring: -Most of DistributedZkUpdateProcessor's SHARED replica logic is moved into a new SharedCoreIndexingBatchProcessor. The purpose of this class is to pull from the shared store at the start of an indexing batch (if the core is stale) and push to the shared store at the end of a successfully committed indexing batch. -CoreUpdateTracker has been deleted and its only persistShardIndexToSharedStore method has been renamed to pushCoreToSharedStore and moved to CorePusher. -BlobStoreUtilsTest#syncLocalCoreWithSharedStore is renamed to pullCoreFromSharedStore and moved into a new CorePuller class and the tests to CorePullerTests. -I did rename phrase "blob store" to "shared store" at some places in the changed classes. But it was not meant to be an exhaustive attempt. * -Throw error for pull request for an unknown. -Log warning when indexing a non-active shard. * Address CR feedback. > Shared storage support in SolrCloud > --- > > Key: SOLR-13101 > URL: https://issues.apache.org/jira/browse/SOLR-13101 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Yonik Seeley >Priority: Major > Time Spent: 15h 50m > Remaining Estimate: 0h > > Solr should have first-class support for shared storage (blob/object stores > like S3, google cloud storage, etc. and shared filesystems like HDFS, NFS, > etc). > The key component will likely be a new replica type for shared storage. It > would have many of the benefits of the current "pull" replicas (not indexing > on all replicas, all shards identical with no shards getting out-of-sync, > etc), but would have additional benefits: > - Any shard could become leader (the blob store always has the index) > - Better elasticity scaling down >- durability not linked to number of replcias.. a single replica could be > common for write workloads >- could drop to 0 replicas for a shard when not needed (blob store always > has index) > - Allow for higher performance write workloads by skipping the transaction > log >- don't pay for what you don't need >- a commit will be necessary to flush to stable storage (blob store) > - A lot of the complexity and failure modes go away > An additional component a Directory implementation that will work well with > blob stores. We probably want one that treats local disk as a cache since > the latency to remote storage is so large. I think there are still some > "locking" issues to be solved here (ensuring that more than one writer to the > same index won't corrupt it). This should probably be pulled out into a > different JIRA issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12823) remove clusterstate.json in Lucene/Solr 8.0
[ https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110542#comment-17110542 ] Ilan Ginzburg commented on SOLR-12823: -- Anybody feels strongly *against* deleting BasicZkTest? This test seems to be a mix of unrelated concerns, does ZK but not really SolrCloud and I believe most/all of what it's trying to test (which isn't clear to me TBH) is tested elsewhere. > remove clusterstate.json in Lucene/Solr 8.0 > --- > > Key: SOLR-12823 > URL: https://issues.apache.org/jira/browse/SOLR-12823 > Project: Solr > Issue Type: Task >Reporter: Varun Thacker >Priority: Major > > clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove > that in 8.0 > It stays empty unless you explicitly ask to create the collection with the > old "stateFormat" and there is no reason for one to create a collection with > the old stateFormat. > We should also remove the "stateFormat" argument in create collection > We should also remove MIGRATESTATEVERSION as well > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13101) Shared storage support in SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110541#comment-17110541 ] ASF subversion and git services commented on SOLR-13101: Commit 738dbb35c7c1db82141d90b200c0bc69c6fa1b9b in lucene-solr's branch refs/heads/jira/SOLR-13101 from Andy Vuong [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=738dbb3 ] SOLR-13101: Enable shared store via system property only (#1424) > Shared storage support in SolrCloud > --- > > Key: SOLR-13101 > URL: https://issues.apache.org/jira/browse/SOLR-13101 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: Yonik Seeley >Priority: Major > Time Spent: 15.5h > Remaining Estimate: 0h > > Solr should have first-class support for shared storage (blob/object stores > like S3, google cloud storage, etc. and shared filesystems like HDFS, NFS, > etc). > The key component will likely be a new replica type for shared storage. It > would have many of the benefits of the current "pull" replicas (not indexing > on all replicas, all shards identical with no shards getting out-of-sync, > etc), but would have additional benefits: > - Any shard could become leader (the blob store always has the index) > - Better elasticity scaling down >- durability not linked to number of replcias.. a single replica could be > common for write workloads >- could drop to 0 replicas for a shard when not needed (blob store always > has index) > - Allow for higher performance write workloads by skipping the transaction > log >- don't pay for what you don't need >- a commit will be necessary to flush to stable storage (blob store) > - A lot of the complexity and failure modes go away > An additional component a Directory implementation that will work well with > blob stores. We probably want one that treats local disk as a cache since > the latency to remote storage is so large. I think there are still some > "locking" issues to be solved here (ensuring that more than one writer to the > same index won't corrupt it). This should probably be pulled out into a > different JIRA issue. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley merged pull request #1424: SOLR-13101: Enable shared store via system property only
dsmiley merged pull request #1424: URL: https://github.com/apache/lucene-solr/pull/1424 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14482) Fix or suppress warnings in solr/search/facet
[ https://issues.apache.org/jira/browse/SOLR-14482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110536#comment-17110536 ] Erick Erickson commented on SOLR-14482: --- Ignore that PR, I'm reworking trhe code. > Fix or suppress warnings in solr/search/facet > - > > Key: SOLR-14482 > URL: https://issues.apache.org/jira/browse/SOLR-14482 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Taking this on next since I've just worked on it in SOLR-10810. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-12823) remove clusterstate.json in Lucene/Solr 8.0
[
https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110537#comment-17110537
]
David Smiley commented on SOLR-12823:
-
{quote}After implementing a cleaner Json return that looked good in response to
a GET request but broke the UI
{quote}
Consider /admin/zookeeper to be newly deprecate in lieu of a superior
replacement [~noble.paul] recently pushed – SOLR-13942
> remove clusterstate.json in Lucene/Solr 8.0
> ---
>
> Key: SOLR-12823
> URL: https://issues.apache.org/jira/browse/SOLR-12823
> Project: Solr
> Issue Type: Task
>Reporter: Varun Thacker
>Priority: Major
>
> clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove
> that in 8.0
> It stays empty unless you explicitly ask to create the collection with the
> old "stateFormat" and there is no reason for one to create a collection with
> the old stateFormat.
> We should also remove the "stateFormat" argument in create collection
> We should also remove MIGRATESTATEVERSION as well
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson closed pull request #1519: SOLR-14482: Fix compile-time warnings in solr/core/search/facet
ErickErickson closed pull request #1519: URL: https://github.com/apache/lucene-solr/pull/1519 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson commented on pull request #1519: SOLR-14482: Fix compile-time warnings in solr/core/search/facet
ErickErickson commented on pull request #1519: URL: https://github.com/apache/lucene-solr/pull/1519#issuecomment-630376772 Reworking, I'll put up another PR. 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1497: SOLR-8394: /admin/luke didn't computeindexHeapUsageBytes
dsmiley commented on a change in pull request #1497:
URL: https://github.com/apache/lucene-solr/pull/1497#discussion_r426829924
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/LukeRequestHandler.java
##
@@ -634,17 +635,19 @@ private static long getSegmentsFileLength(IndexCommit
commit) {
/** Returns the sum of RAM bytes used by each segment */
private static long getIndexHeapUsed(DirectoryReader reader) {
-long indexHeapRamBytesUsed = 0;
-for(LeafReaderContext leafReaderContext : reader.leaves()) {
- LeafReader leafReader = leafReaderContext.reader();
- if (leafReader instanceof SegmentReader) {
-indexHeapRamBytesUsed += ((SegmentReader) leafReader).ramBytesUsed();
- } else {
-// Not supported for any reader that is not a SegmentReader
-return -1;
- }
-}
-return indexHeapRamBytesUsed;
+return reader.leaves().stream()
+.map(LeafReaderContext::reader)
+.map(FilterLeafReader::unwrap)
+.map(leafReader -> {
+ if (leafReader instanceof Accountable) {
Review comment:
Feel free to suggest a code snippet; I'm not sure I get it.
One small improvement I see I could make was change the last "map" call to
be a "mapToLong" instead, and then I can remove the last mapToLong.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9074) Account for Executor's Queue Length When Planning Slices in IndexSearcher
[ https://issues.apache.org/jira/browse/LUCENE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma resolved LUCENE-9074. - Resolution: Fixed > Account for Executor's Queue Length When Planning Slices in IndexSearcher > - > > Key: LUCENE-9074 > URL: https://issues.apache.org/jira/browse/LUCENE-9074 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 10h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9074) Account for Executor's Queue Length When Planning Slices in IndexSearcher
[ https://issues.apache.org/jira/browse/LUCENE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110501#comment-17110501 ] Atri Sharma commented on LUCENE-9074: - No, this Jira is completed. Sorry, I forgot to close this after completion. > Account for Executor's Queue Length When Planning Slices in IndexSearcher > - > > Key: LUCENE-9074 > URL: https://issues.apache.org/jira/browse/LUCENE-9074 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 10h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14495) Fix or suppress warnings in solr/search/function
[ https://issues.apache.org/jira/browse/SOLR-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110494#comment-17110494 ] Erick Erickson commented on SOLR-14495: --- I'll commit this PR Wednesday barring objections. > Fix or suppress warnings in solr/search/function > > > Key: SOLR-14495 > URL: https://issues.apache.org/jira/browse/SOLR-14495 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson opened a new pull request #1526: SOLR-14495: Fix or suppress warnings in solr/search/function
ErickErickson opened a new pull request #1526: URL: https://github.com/apache/lucene-solr/pull/1526 I'll push this Wednesday or so barring objections 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14496) Add basic auth support to postlogs
Joel Bernstein created SOLR-14496: - Summary: Add basic auth support to postlogs Key: SOLR-14496 URL: https://issues.apache.org/jira/browse/SOLR-14496 Project: Solr Issue Type: New Feature Security Level: Public (Default Security Level. Issues are Public) Reporter: Joel Bernstein This ticket will allow the postlogs tool to post basic auth credentials. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14496) Add basic auth support to postlogs
[ https://issues.apache.org/jira/browse/SOLR-14496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-14496: -- Description: This ticket will allow the postlogs tool to use basic auth credentials. (was: This ticket will allow the postlogs tool to post basic auth credentials.) > Add basic auth support to postlogs > -- > > Key: SOLR-14496 > URL: https://issues.apache.org/jira/browse/SOLR-14496 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Joel Bernstein >Priority: Major > > This ticket will allow the postlogs tool to use basic auth credentials. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14443) Make SolrLogPostTool resilient to unexpected requests
[ https://issues.apache.org/jira/browse/SOLR-14443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110465#comment-17110465 ] Jason Gerlowski commented on SOLR-14443: Pushed up a PR for this. Changes are pretty trivial, so I'll merge by the end of the week if I don't get any feedback. > Make SolrLogPostTool resilient to unexpected requests > - > > Key: SOLR-14443 > URL: https://issues.apache.org/jira/browse/SOLR-14443 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: scripts and tools >Affects Versions: master (9.0) >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Trivial > Time Spent: 10m > Remaining Estimate: 0h > > When SolrLogPostTool parses log messages corresponding to incoming requests, > it sets various predefined fields based on the parameters on the request. > e.g. it sets a rows_i field, a wt_s field, and so on. > This logic works for most requests, but if the log-parser encounters requests > with multiple of these params (e.g. rows), it will blithely add them to the > SolrInputDocument, and error out when Solr rejects the eventual update > request because it is attempting to put multiple values into a single-valued > field. > We can do two things to fix this. > # Make SolrLogPostTool's "posting" code resilient to individual update > failures. It doesn't make any sense to crash the entire posting routine just > because one batch (or one log message) was malformed. > # Tweak the field parsing logic to be more resilient to the specific > "redundant query params" case I encountered specifically here. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Assigned] (SOLR-14476) Add percentiles and standard deviation aggregations to stats, facet and timeseries Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein reassigned SOLR-14476:
-
Assignee: Joel Bernstein
> Add percentiles and standard deviation aggregations to stats, facet and
> timeseries Streaming Expressions
>
>
> Key: SOLR-14476
> URL: https://issues.apache.org/jira/browse/SOLR-14476
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch,
> SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch
>
>
> This ticket will add the *per* (percentile) and *std* (standard deviation)
> aggregations to the *stats*, *facet* and *timeseries* Streaming Expressions.
> Syntax:
>
> {code:java}
> facet(logs, buckets="collection_s", per(qtime_i, 50), std(qtime_i)) {code}
> The stats function will also be reimplemented using JSON facets rather than
> the stats component as part of this ticket. The main reason is that JSON
> facets syntax is easier to work with for percentiles, but it also
> standardized are pushed down aggregations to JSON facets.
> In a separate ticket *per* and *std* aggregations will be added to the
> *rollup*, *hashRollup* and *nodes* Streaming Expressions.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14476) Add percentiles and standard deviation aggregations to stats, facet and timeseries Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-14476:
--
Attachment: SOLR-14476.patch
> Add percentiles and standard deviation aggregations to stats, facet and
> timeseries Streaming Expressions
>
>
> Key: SOLR-14476
> URL: https://issues.apache.org/jira/browse/SOLR-14476
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch,
> SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch
>
>
> This ticket will add the *per* (percentile) and *std* (standard deviation)
> aggregations to the *stats*, *facet* and *timeseries* Streaming Expressions.
> Syntax:
>
> {code:java}
> facet(logs, buckets="collection_s", per(qtime_i, 50), std(qtime_i)) {code}
> The stats function will also be reimplemented using JSON facets rather than
> the stats component as part of this ticket. The main reason is that JSON
> facets syntax is easier to work with for percentiles, but it also
> standardized are pushed down aggregations to JSON facets.
> In a separate ticket *per* and *std* aggregations will be added to the
> *rollup*, *hashRollup* and *nodes* Streaming Expressions.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] gerlowskija opened a new pull request #1525: SOLR-14443: Make SolrLogPostTool resilient to odd requests
gerlowskija opened a new pull request #1525: URL: https://github.com/apache/lucene-solr/pull/1525 #1418 Description SolrLogPostTool is relatively brittle in how it indexes log records to Solr. A single error from Solr causes the tool to crash. Further, when user requests have duplicate or unnecessary parameters, the tool attempts to record all of these (even when the field used is singlevalued). As a result, a single "oddball" request crashes the whole ingestion run. # Solution This PR makes two related changes. First, it changes SolrLogPostTool's batching code to log (but ultimately ignore) errors. This allows an indexing run to survive malformed records or other indexing blips. Second, it changes the record-parsing code to only record single values for single-valued log record fields. This prevents a common cause of malformed records. # Tests Manual testing, in addition to a test case added to SolrLogPostToolTest # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [x] I have run `ant precommit` and the appropriate test suite. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
uschindler commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r426715844
##
File path: gradle/validation/check-broken-links.gradle
##
@@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+configure(rootProject) {
+
+ task checkBrokenLinks {
+group 'Verification'
+description 'Check broken links in the entire documentation'
+
+dependsOn ':lucene:checkBrokenLinks'
+dependsOn ':solr:checkBrokenLinks'
+ }
+
+}
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+
+ task checkBrokenLinks(type: CheckBrokenLinksTask, 'dependsOn':
'documentation')
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn checkBrokenLinks
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+
+ @Input
+ Provider docsDir = project.providers.provider { project.docroot }
+
+ @Input
Review comment:
same here
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
uschindler commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r426715760
##
File path: gradle/validation/check-broken-links.gradle
##
@@ -0,0 +1,68 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+configure(rootProject) {
+
+ task checkBrokenLinks {
+group 'Verification'
+description 'Check broken links in the entire documentation'
+
+dependsOn ':lucene:checkBrokenLinks'
+dependsOn ':solr:checkBrokenLinks'
+ }
+
+}
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+
+ task checkBrokenLinks(type: CheckBrokenLinksTask, 'dependsOn':
'documentation')
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn checkBrokenLinks
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+
+ @Input
Review comment:
Should be `@InputFile`
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2150) Anti-phrasing feature
[ https://issues.apache.org/jira/browse/SOLR-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-2150. --- Resolution: Won't Do I close this as 3rd party plugins like [https://github.com/querqy/querqy] already support similar features, including the configurable setting of filters as hoss suggested. In addition the [https://solr.cool|https://solr.cool/] guys are in the process of converting the plugins into Solr Packages for easy install, which will make them more available. > Anti-phrasing feature > - > > Key: SOLR-2150 > URL: https://issues.apache.org/jira/browse/SOLR-2150 > Project: Solr > Issue Type: New Feature > Components: SearchComponents - other >Reporter: Jan Høydahl >Priority: Major > > Add an anti-phrasing feature to Solr. > Definition: Identifying word sequences in queries that do not contribute > essentially to the query's meaning, such as "Where can I find" or "Where is." > (Source: http://www.google.com/search?q=define%3Aanti+phrasing) > For general purpose search services, such as web, intranet, shopping search, > some users will try to write a question to the search engine, such as "how > much is an ipod nano". One straight-forward way of limiting the number of > 0-hits in such environments is to apply anti-phrasing, which uses a > dictionary of common sentence prefixes which should be stripped from the > incoming query before it is sent further to search. > This can be implemented as a Search Component in Solr. The dictionary can be > language independent. We can encourage users to submit their tested > anti-phrasing dictionaries for various languages, and include those. The > dictionary can be a set of simple .txt files, loaded in memory at startup in > an efficient data structure such as b-tree or finite state automaton to avoid > redundancy and ensure quick matching. The procedure for detecting an > anti-phrase from the incoming query is to first lookup the full query phrase, > if no match, remove a word from the end, and do another lookup until either a > match or end of string. Example for query: "Who is Einstein?", where "Who is" > is defined as an anti phrase. > 1. Lookup "Who is Einstein" > 2. Lookup "Who is" (match), remove this prefix > 3. Issue the query "Einstein" to search -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-2149) Allow copyField directives to be controled by another (boolean) field
[
https://issues.apache.org/jira/browse/SOLR-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl resolved SOLR-2149.
---
Resolution: Won't Do
> Allow copyField directives to be controled by another (boolean) field
> -
>
> Key: SOLR-2149
> URL: https://issues.apache.org/jira/browse/SOLR-2149
> Project: Solr
> Issue Type: New Feature
>Reporter: Peter Wolanin
>Priority: Major
> Attachments: SOLR-2149.patch
>
>
> Thinking about alternative approaches to the problem outlined in SOLR-2010,
> it occurs to me that there are many cases where it would be useful to be able
> to control copyField behavior rather than having to fully populate or omit
> document fields. In regards to spellcheck, I could then have a few different
> spellcheck indexes each built from a different field and indicate for each
> document whether it's text should be added to each of the different
> spellcheck fields.
> I'm imagining a general syntax like this:
> {code}
> controlField="populate_teaser"/>
> {code}
> If not sure if Solr would could use the value of a control field only matches
> the "ignored" field type, but that's what I'm thinking about as one
> possibility. In other words, I can pass index-time flags into the document
> that are reflected in the terms of what's indexed but not explicitly stored
> in the document.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (SOLR-1978) Create MappingTokenFilterFactory
[ https://issues.apache.org/jira/browse/SOLR-1978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved SOLR-1978. --- Resolution: Won't Do > Create MappingTokenFilterFactory > > > Key: SOLR-1978 > URL: https://issues.apache.org/jira/browse/SOLR-1978 > Project: Solr > Issue Type: New Feature > Components: Schema and Analysis >Reporter: Jan Høydahl >Priority: Minor > > There is a need for a mapping filter as a counterpart for the > MappingCharFilterFactory, but designed to run after tokenization. It should > read the same config file format as the MappingCharFilterFactory does. > This will be a more generic approach to accent normalization than the > ISOLatin1AccentFilterFactory which is hard coded. > The reason why we need it as a TokenFilter is that sometimes the > normalization needs to happen far down in the analysis chain, because > previous filters rely on the original value of the token, such as stemming, > synonyms or other dictionary lookups. > This patch would require a MappingTokenFilter in Lucene as well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9074) Account for Executor's Queue Length When Planning Slices in IndexSearcher
[ https://issues.apache.org/jira/browse/LUCENE-9074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110368#comment-17110368 ] Adrien Grand commented on LUCENE-9074: -- [~atri] Is there anything that remains to be done on this JIRA? > Account for Executor's Queue Length When Planning Slices in IndexSearcher > - > > Key: LUCENE-9074 > URL: https://issues.apache.org/jira/browse/LUCENE-9074 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 10h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14142) Enable jetty's request log by default
[ https://issues.apache.org/jira/browse/SOLR-14142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110360#comment-17110360 ] Robert Muir commented on SOLR-14142: Oops, I forgot about this issue entirely. I'll take another look later today. > Enable jetty's request log by default > - > > Key: SOLR-14142 > URL: https://issues.apache.org/jira/browse/SOLR-14142 > Project: Solr > Issue Type: Improvement >Reporter: Robert Muir >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-14142.patch, SOLR-14142.patch > > > I'd like to enable the jetty request log by default. > This log is now in the correct directory, it no longer uses the deprecated > mechanisms (it is asynclogwriter + customformat), etc. See SOLR-14138. > This log is in a standard format (NCSA) which is supported by tools > out-of-box. It does not contain challenges such as java exceptions and is > easy to work with. Without it enabled, solr really has insufficient logging > (e.g. no IP addresses). > If someone's solr gets hacked, its only fair they at least get to see who did > it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9333) Gradle task equivalent to ant's "change-to-html"
[ https://issues.apache.org/jira/browse/LUCENE-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110348#comment-17110348 ] ASF subversion and git services commented on LUCENE-9333: - Commit 10d1ecb431c3bd0a0c8995d65db14a1a5bc85094 in lucene-solr's branch refs/heads/master from Tomoko Uchida [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=10d1ecb ] LUCENE-9333: lazily evaluate for 'docroot' property > Gradle task equivalent to ant's "change-to-html" > > > Key: LUCENE-9333 > URL: https://issues.apache.org/jira/browse/LUCENE-9333 > Project: Lucene - Core > Issue Type: Task > Components: general/build >Affects Versions: master (9.0) >Reporter: Tomoko Uchida >Assignee: Tomoko Uchida >Priority: Major > Fix For: master (9.0) > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14454) support for UTF-8 (string) types with DocValuesType.BINARY
[
https://issues.apache.org/jira/browse/SOLR-14454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110345#comment-17110345
]
Michael Gibney commented on SOLR-14454:
---
Thanks! It definitely makes sense to consider support for multiValued. I'll
take a look at TextField, and agree it would makes sense to add this
functionality there. I initially went completely orthogonal to TextField,
relating changes to {{isUtf8Field()}}, because I wanted to keep the patch as
small as possible while still enabling missing functionality.
> support for UTF-8 (string) types with DocValuesType.BINARY
> --
>
> Key: SOLR-14454
> URL: https://issues.apache.org/jira/browse/SOLR-14454
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Schema and Analysis
>Affects Versions: master (9.0)
>Reporter: Michael Gibney
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The goal is to add support for string fields with arbitrarily large values in
> the {{/export}} handler and streaming expressions.
> {{StrField}} values are currently limited to 32766 bytes for the case where
> {{indexed=true}} or {{docValues=true}}. Exceeding this value triggers an
> "immense field" warning, and causes indexing to fail for the associated input
> doc.
> Configuring a {{StrField}} field as "{{indexed=false docValues=false}}"
> removes this size limitation, so it is already possible to have large
> _stored_ {{StrField}} values. But the "{{docValues=true}}" prerequisite for
> the {{/export}} handler (and consequently for streaming expressions) limits
> the size of field that can be used in conjunction with these features.
> Adding support for UTF-8/string field types with {{DocValuesType.BINARY}}
> would address this limitation and allow considerable flexibility in the
> implementation of custom field types. N.b.: this would address field value
> retrieval use cases only (e.g., {{/export}} and {{useDocValuesAsStored}});
> neither sorting nor faceting would be supported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14142) Enable jetty's request log by default
[ https://issues.apache.org/jira/browse/SOLR-14142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110334#comment-17110334 ] Jan Høydahl commented on SOLR-14142: +1 > Enable jetty's request log by default > - > > Key: SOLR-14142 > URL: https://issues.apache.org/jira/browse/SOLR-14142 > Project: Solr > Issue Type: Improvement >Reporter: Robert Muir >Priority: Major > Fix For: master (9.0) > > Attachments: SOLR-14142.patch, SOLR-14142.patch > > > I'd like to enable the jetty request log by default. > This log is now in the correct directory, it no longer uses the deprecated > mechanisms (it is asynclogwriter + customformat), etc. See SOLR-14138. > This log is in a standard format (NCSA) which is supported by tools > out-of-box. It does not contain challenges such as java exceptions and is > easy to work with. Without it enabled, solr really has insufficient logging > (e.g. no IP addresses). > If someone's solr gets hacked, its only fair they at least get to see who did > it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] mocobeta commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
mocobeta commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r426656931
##
File path: gradle/validation/documentation-lint.gradle
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+configure(rootProject) {
+
+ task documentationLint {
+group 'Verification'
+description 'Verify all documentation'
+
+dependsOn 'documentation'
+dependsOn subprojects.collect { prj ->
+ prj.tasks.matching { task -> task.name == 'checkBrokenLinks'}
+}
+ }
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn documentationLint
+}
+
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+ task checkBrokenLinks(type: CheckBrokenLinksTask)
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+ @Input
+ File docsDir = project.docroot
Review comment:
Thanks for the pointers. `project.providers.provider { project.docroot
}` perfectly works for me.
https://github.com/apache/lucene-solr/pull/1522/commits/ac195d147a3b7d25605ca98034028f9719913782
(`${->project.docroot}` also works fine; I like using `Provider`
signature here.)
On the master branch, `gradlew renderSiteJavadoc` fails with this error when
I reverse evaluation order of `gradle/render-javadoc.gradle` and
`gradle/documentation/documentation.gradle`.
```
> Could not get unknown property 'docroot' for project ':solr:core' of type
org.gradle.api.Project.
```
I think it'd be better doing the same for render-javadoc.gradle just for
safety, or add some comments about the ordering on `build.gradle` to prevent
someone accidentally changes the file?
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14476) Add percentiles and standard deviation aggregations to stats, facet and timeseries Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-14476:
--
Attachment: SOLR-14476.patch
> Add percentiles and standard deviation aggregations to stats, facet and
> timeseries Streaming Expressions
>
>
> Key: SOLR-14476
> URL: https://issues.apache.org/jira/browse/SOLR-14476
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch,
> SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch
>
>
> This ticket will add the *per* (percentile) and *std* (standard deviation)
> aggregations to the *stats*, *facet* and *timeseries* Streaming Expressions.
> Syntax:
>
> {code:java}
> facet(logs, buckets="collection_s", per(qtime_i, 50), std(qtime_i)) {code}
> The stats function will also be reimplemented using JSON facets rather than
> the stats component as part of this ticket. The main reason is that JSON
> facets syntax is easier to work with for percentiles, but it also
> standardized are pushed down aggregations to JSON facets.
> In a separate ticket *per* and *std* aggregations will be added to the
> *rollup*, *hashRollup* and *nodes* Streaming Expressions.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] janhoy commented on a change in pull request #1403: SOLR-9679: Exception when removing zk node /security.json
janhoy commented on a change in pull request #1403:
URL: https://github.com/apache/lucene-solr/pull/1403#discussion_r426598653
##
File path:
solr/core/src/test/org/apache/solr/security/BasicAuthOnSingleNodeTest.java
##
@@ -45,13 +45,13 @@ public void setupCluster() throws Exception {
.setBasicAuthCredentials("solr", "solr")
.process(cluster.getSolrClient());
cluster.waitForActiveCollection(COLLECTION, 4, 4);
+ }
-JettySolrRunner jetty = cluster.getJettySolrRunner(0);
Review comment:
I removed this part of initialization - don't see why we should tear
down and recreate cluster every time?
##
File path:
solr/core/src/test/org/apache/solr/security/BasicAuthOnSingleNodeTest.java
##
@@ -45,13 +45,13 @@ public void setupCluster() throws Exception {
.setBasicAuthCredentials("solr", "solr")
.process(cluster.getSolrClient());
cluster.waitForActiveCollection(COLLECTION, 4, 4);
+ }
-JettySolrRunner jetty = cluster.getJettySolrRunner(0);
-jetty.stop();
-cluster.waitForJettyToStop(jetty);
-jetty.start();
-cluster.waitForAllNodes(30);
-cluster.waitForActiveCollection(COLLECTION, 4, 4);
+ @Override
+ @After
+ public void tearDown() throws Exception {
+cluster.shutdown();
Review comment:
With just one test in this class, resource cleanup happened
automatically at the end I guess, but with two methods, we need to shutdown
cluster in `tearDown`...
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson closed pull request #1406: SOLR-14388: Remove references to rule-based replica placement in the ref guide
ErickErickson closed pull request #1406: URL: https://github.com/apache/lucene-solr/pull/1406 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14479) Fix or suppress warnings in solr/core/analysis
[ https://issues.apache.org/jira/browse/SOLR-14479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-14479: -- Summary: Fix or suppress warnings in solr/core/analysis (was: Get a clean compile of solr/core/analysis) > Fix or suppress warnings in solr/core/analysis > -- > > Key: SOLR-14479 > URL: https://issues.apache.org/jira/browse/SOLR-14479 > Project: Solr > Issue Type: Sub-task > Components: Build >Reporter: Erick Erickson >Assignee: Gus Heck >Priority: Major > > [~gus] Ask and ye shall receive. > Here's how I'd like to approach this: > * Let's start with solr/core, one subdirectory at a time. > * See SOLR-14474 for how we want to address auxiliary classes, especially > the question to move them to their own file or nest them. It'll be fuzzy > until we get some more experience. > * Let's just clean everything up _except_ deprecations. My thinking here is > that there will be a bunch of code changes that we can/should backport to 8x > to clean up the warnings. Deprecations will be (probably) 9.0 only so > there'll be fewer problems with maintaining the two branches if we leave > deprecations out of the mix for the present. > * Err on the side of adding @SuppressWarnings rather than code changes for > this phase. If it's reasonably safe to change the code (say by adding ) do > so, but substantive changes are too likely to have unintended consequences. > I'd like to reach a consensus on what changes are "safe", that'll probably be > an ongoing discussion as we run into them for a while. > * I expect there'll be a certain amount of stepping on each other's toes, no > doubt to clean some things up in one of the subdirectories we'll have to > change something in an ancestor directory, but we can deal with those as they > come up, probably that'll just mean merging the current master with the fork > we're working on... > Let me know what you think or if you'd like to change the approach. > Oh, and all I did here was take the first subdirectory of solr/core that I > found, feel free to take on something else. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14480) Fix or suppress warnings in solr/core/api
[ https://issues.apache.org/jira/browse/SOLR-14480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-14480: -- Summary: Fix or suppress warnings in solr/core/api (was: Get a clean compile of solr/core/api) > Fix or suppress warnings in solr/core/api > - > > Key: SOLR-14480 > URL: https://issues.apache.org/jira/browse/SOLR-14480 > Project: Solr > Issue Type: Sub-task > Components: Build >Reporter: Erick Erickson >Assignee: Atri Sharma >Priority: Major > > [~atri] Here's one for you! > Here's how I'd like to approach this: > * Let's start with solr/core, one subdirectory at a time. > * See SOLR-14474 for how we want to address auxiliary classes, especially > the question to move them to their own file or nest them. It'll be fuzzy > until we get some more experience. > * Let's just clean everything up _except_ deprecations. My thinking here is > that there will be a bunch of code changes that we can/should backport to 8x > to clean up the warnings. Deprecations will be (probably) 9.0 only so > there'll be fewer problems with maintaining the two branches if we leave > deprecations out of the mix for the present. > * Err on the side of adding @SuppressWarnings rather than code changes for > this phase. If it's reasonably safe to change the code (say by adding ) do > so, but substantive changes are too likely to have unintended consequences. > I'd like to reach a consensus on what changes are "safe", that'll probably be > an ongoing discussion as we run into them for a while. > * I expect there'll be a certain amount of stepping on each other's toes, no > doubt to clean some things up in one of the subdirectories we'll have to > change something in an ancestor directory, but we can deal with those as they > come up, probably that'll just mean merging the current master with the fork > we're working on... > Let me know what you think or if you'd like to change the approach. > Oh, and all I did here was take the second subdirectory of solr/core that I > found, feel free to take on something else. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14495) Fix or suppress warnings in solr/search/function
[ https://issues.apache.org/jira/browse/SOLR-14495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-14495: -- Summary: Fix or suppress warnings in solr/search/function (was: Get warnings out of solr/search/function) > Fix or suppress warnings in solr/search/function > > > Key: SOLR-14495 > URL: https://issues.apache.org/jira/browse/SOLR-14495 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14482) Fix or suppress warnings in solr/search/facet
[ https://issues.apache.org/jira/browse/SOLR-14482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-14482: -- Summary: Fix or suppress warnings in solr/search/facet (was: Fix compile-time warnings in solr/search/facet) > Fix or suppress warnings in solr/search/facet > - > > Key: SOLR-14482 > URL: https://issues.apache.org/jira/browse/SOLR-14482 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Taking this on next since I've just worked on it in SOLR-10810. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14476) Add percentiles and standard deviation aggregations to stats, facet and timeseries Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Bernstein updated SOLR-14476:
--
Attachment: SOLR-14476.patch
> Add percentiles and standard deviation aggregations to stats, facet and
> timeseries Streaming Expressions
>
>
> Key: SOLR-14476
> URL: https://issues.apache.org/jira/browse/SOLR-14476
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: streaming expressions
>Reporter: Joel Bernstein
>Priority: Major
> Attachments: SOLR-14476.patch, SOLR-14476.patch, SOLR-14476.patch,
> SOLR-14476.patch, SOLR-14476.patch
>
>
> This ticket will add the *per* (percentile) and *std* (standard deviation)
> aggregations to the *stats*, *facet* and *timeseries* Streaming Expressions.
> Syntax:
>
> {code:java}
> facet(logs, buckets="collection_s", per(qtime_i, 50), std(qtime_i)) {code}
> The stats function will also be reimplemented using JSON facets rather than
> the stats component as part of this ticket. The main reason is that JSON
> facets syntax is easier to work with for percentiles, but it also
> standardized are pushed down aggregations to JSON facets.
> In a separate ticket *per* and *std* aggregations will be added to the
> *rollup*, *hashRollup* and *nodes* Streaming Expressions.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] juanka588 commented on a change in pull request #1497: SOLR-8394: /admin/luke didn't computeindexHeapUsageBytes
juanka588 commented on a change in pull request #1497:
URL: https://github.com/apache/lucene-solr/pull/1497#discussion_r426510323
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/LukeRequestHandler.java
##
@@ -634,17 +635,19 @@ private static long getSegmentsFileLength(IndexCommit
commit) {
/** Returns the sum of RAM bytes used by each segment */
private static long getIndexHeapUsed(DirectoryReader reader) {
-long indexHeapRamBytesUsed = 0;
-for(LeafReaderContext leafReaderContext : reader.leaves()) {
- LeafReader leafReader = leafReaderContext.reader();
- if (leafReader instanceof SegmentReader) {
-indexHeapRamBytesUsed += ((SegmentReader) leafReader).ramBytesUsed();
- } else {
-// Not supported for any reader that is not a SegmentReader
-return -1;
- }
-}
-return indexHeapRamBytesUsed;
+return reader.leaves().stream()
+.map(LeafReaderContext::reader)
+.map(FilterLeafReader::unwrap)
+.map(leafReader -> {
+ if (leafReader instanceof Accountable) {
Review comment:
or map into accountable returning -1L
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] juanka588 commented on a change in pull request #1497: SOLR-8394: /admin/luke didn't computeindexHeapUsageBytes
juanka588 commented on a change in pull request #1497:
URL: https://github.com/apache/lucene-solr/pull/1497#discussion_r426509706
##
File path:
solr/core/src/java/org/apache/solr/handler/admin/LukeRequestHandler.java
##
@@ -634,17 +635,19 @@ private static long getSegmentsFileLength(IndexCommit
commit) {
/** Returns the sum of RAM bytes used by each segment */
private static long getIndexHeapUsed(DirectoryReader reader) {
-long indexHeapRamBytesUsed = 0;
-for(LeafReaderContext leafReaderContext : reader.leaves()) {
- LeafReader leafReader = leafReaderContext.reader();
- if (leafReader instanceof SegmentReader) {
-indexHeapRamBytesUsed += ((SegmentReader) leafReader).ramBytesUsed();
- } else {
-// Not supported for any reader that is not a SegmentReader
-return -1;
- }
-}
-return indexHeapRamBytesUsed;
+return reader.leaves().stream()
+.map(LeafReaderContext::reader)
+.map(FilterLeafReader::unwrap)
+.map(leafReader -> {
+ if (leafReader instanceof Accountable) {
Review comment:
can we filter here instead?
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] uschindler commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
uschindler commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r426401368
##
File path: gradle/validation/documentation-lint.gradle
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+configure(rootProject) {
+
+ task documentationLint {
+group 'Verification'
+description 'Verify all documentation'
+
+dependsOn 'documentation'
+dependsOn subprojects.collect { prj ->
+ prj.tasks.matching { task -> task.name == 'checkBrokenLinks'}
+}
+ }
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn documentationLint
+}
+
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+ task checkBrokenLinks(type: CheckBrokenLinksTask)
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+ @Input
+ File docsDir = project.docroot
Review comment:
You can use a `DirectoryProperty` instead of a File and then use
`providers.property{...}` to assign value. Gradle DSL does not change, just
when using it from Groovy code or Java code, you have to call
`.getAsFile().get()` (which does lazy evaluation).
I did not use that for render-javadocs, becuase it was not needed.
Another "simple" way for lazy evaluation (works only with Strings, but its
often helpful) is to use GString (double quoted Strings): `GString someProperty
= "${->project.docroot}"` (please note the `->`). Whenever `toString()` or `as
String` is called, its lazinly evaluated. Without the `->` the value is
inserted into the string at parsing time.
I had the same problem with #1477, but I will plan to do this for the URL
coming from an extension:
```groovy
@Input
def luceneDocUrl = "${->project.luceneDocUrl}"
@Input
def solrDocUrl = "${->project.solrDocUrl}"
```
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] markharwood commented on pull request #1521: Lucene-9371: Allow external access to RegExp's parsed structure
markharwood commented on pull request #1521: URL: https://github.com/apache/lucene-solr/pull/1521#issuecomment-630060662 Thanks for looking at this, Mike! 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1432: SOLR-14404 CoreContainer level custom requesthandlers
noblepaul commented on a change in pull request #1432:
URL: https://github.com/apache/lucene-solr/pull/1432#discussion_r426452163
##
File path:
solr/core/src/test/org/apache/solr/handler/admin/TestApiFramework.java
##
@@ -199,6 +200,25 @@ public void testPayload() {
}
+ public void testApiWrapper() {
+Class klas = ApiWithConstructor.class;
Review comment:
it got in there accidentally , removed
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] shalinmangar commented on a change in pull request #1512: SOLR-13325: Add a collection selector to ComputePlanAction
shalinmangar commented on a change in pull request #1512: URL: https://github.com/apache/lucene-solr/pull/1512#discussion_r426438350 ## File path: solr/core/src/java/org/apache/solr/cloud/autoscaling/ComputePlanAction.java ## @@ -17,38 +17,28 @@ package org.apache.solr.cloud.autoscaling; -import java.io.IOException; -import java.lang.invoke.MethodHandles; -import java.util.ArrayList; -import java.util.Collection; -import java.util.Collections; -import java.util.HashSet; -import java.util.List; -import java.util.Map; -import java.util.Set; -import java.util.concurrent.atomic.AtomicInteger; - import org.apache.solr.client.solrj.SolrRequest; import org.apache.solr.client.solrj.cloud.SolrCloudManager; -import org.apache.solr.client.solrj.cloud.autoscaling.AutoScalingConfig; -import org.apache.solr.client.solrj.cloud.autoscaling.NoneSuggester; -import org.apache.solr.client.solrj.cloud.autoscaling.Policy; -import org.apache.solr.client.solrj.cloud.autoscaling.PolicyHelper; -import org.apache.solr.client.solrj.cloud.autoscaling.Suggester; -import org.apache.solr.client.solrj.cloud.autoscaling.UnsupportedSuggester; +import org.apache.solr.client.solrj.cloud.autoscaling.*; import org.apache.solr.common.SolrException; import org.apache.solr.common.cloud.ClusterState; import org.apache.solr.common.cloud.DocCollection; import org.apache.solr.common.cloud.Replica; import org.apache.solr.common.params.AutoScalingParams; import org.apache.solr.common.params.CollectionParams; -import org.apache.solr.common.params.CoreAdminParams; import org.apache.solr.common.util.Pair; import org.apache.solr.common.util.StrUtils; import org.apache.solr.core.SolrResourceLoader; import org.slf4j.Logger; import org.slf4j.LoggerFactory; +import java.io.IOException; +import java.lang.invoke.MethodHandles; +import java.util.*; Review comment: I just imported the project in idea using the gradle scripts. precommit also seems happy. I don't recall a rule about wildcards import? 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 - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] shalinmangar commented on a change in pull request #1512: SOLR-13325: Add a collection selector to ComputePlanAction
shalinmangar commented on a change in pull request #1512:
URL: https://github.com/apache/lucene-solr/pull/1512#discussion_r426437892
##
File path: solr/solr-ref-guide/src/solrcloud-autoscaling-trigger-actions.adoc
##
@@ -29,12 +29,13 @@ commands which can re-balance the cluster in response to
trigger events.
The following parameters are configurable:
`collections`::
-A comma-separated list of collection names. If this list is not empty then
-the computed operations will only calculate collection operations that affect
-listed collections and ignore any other collection operations for collections
+A comma-separated list of collection names. This can also be a selector on the
collection property e.g. `collections: {'policy': 'my_custom_policy'}` will
match all collections which use the policy named `my_customer_policy`.
Review comment:
Thanks. I expanded the description a bit. I added another example that I
am not really happy with -- I cannot think of a use-case where something other
than policy might be useful especially given the fact that values must match
exactly. Suggestions welcome.
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1432: SOLR-14404 CoreContainer level custom requesthandlers
noblepaul commented on a change in pull request #1432:
URL: https://github.com/apache/lucene-solr/pull/1432#discussion_r426434616
##
File path: solr/core/src/test/org/apache/solr/handler/TestContainerPlugin.java
##
@@ -0,0 +1,250 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.handler;
+
+import java.io.IOException;
+import java.util.List;
+import java.util.concurrent.Callable;
+
+import com.google.common.collect.ImmutableMap;
+import org.apache.solr.api.Command;
+import org.apache.solr.api.EndPoint;
+import org.apache.solr.client.solrj.SolrClient;
+import org.apache.solr.client.solrj.SolrServerException;
+import org.apache.solr.client.solrj.impl.BaseHttpSolrClient;
+import org.apache.solr.client.solrj.request.V2Request;
+import org.apache.solr.client.solrj.request.beans.Package;
+import org.apache.solr.client.solrj.request.beans.PluginMeta;
+import org.apache.solr.client.solrj.response.V2Response;
+import org.apache.solr.cloud.MiniSolrCloudCluster;
+import org.apache.solr.cloud.SolrCloudTestCase;
+import org.apache.solr.common.NavigableObject;
+import org.apache.solr.common.util.Utils;
+import org.apache.solr.filestore.PackageStoreAPI;
+import org.apache.solr.filestore.TestDistribPackageStore;
+import org.apache.solr.pkg.TestPackages;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+import org.apache.solr.security.PermissionNameProvider;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Test;
+
+import static java.util.Collections.singletonMap;
+import static org.apache.solr.client.solrj.SolrRequest.METHOD.GET;
+import static org.apache.solr.client.solrj.SolrRequest.METHOD.POST;
+import static org.apache.solr.filestore.TestDistribPackageStore.readFile;
+import static org.apache.solr.filestore.TestDistribPackageStore.uploadKey;
+import static org.hamcrest.CoreMatchers.containsString;
+
+public class TestContainerPlugin extends SolrCloudTestCase {
+
+ @Before
+ public void setup() {
+System.setProperty("enable.packages", "true");
+ }
+
+ @After
+ public void teardown() {
+System.clearProperty("enable.packages");
+ }
+
+ @Test
+ public void testApi() throws Exception {
+MiniSolrCloudCluster cluster =
+configureCluster(4)
+.withJettyConfig(jetty -> jetty.enableV2(true))
+.configure();
+String errPath = "/error/details[0]/errorMessages[0]";
+try {
+ PluginMeta plugin = new PluginMeta();
+ plugin.name = "testplugin";
+ plugin.klass = C2.class.getName();
+ V2Request req = new V2Request.Builder("/cluster/plugin")
+ .forceV2(true)
+ .withMethod(POST)
+ .withPayload(singletonMap("add", plugin))
+ .build();
+ expectError(req, cluster.getSolrClient(), errPath, "Must have a no-arg
constructor or CoreContainer constructor and it must not be a non static inner
class");
+
+ plugin.klass = C1.class.getName();
+ expectError(req, cluster.getSolrClient(), errPath, "Invalid class, no
@EndPoint annotation");
+
+ plugin.klass = C3.class.getName();
+ req.process(cluster.getSolrClient());
+
+ V2Response rsp = new V2Request.Builder("/cluster/plugin")
+ .forceV2(true)
+ .withMethod(GET)
+ .build()
+ .process(cluster.getSolrClient());
+ assertEquals(C3.class.getName(), rsp._getStr("/plugin/testplugin/class",
null));
+
+ TestDistribPackageStore.assertResponseValues(10,
+ () -> new V2Request.Builder("/plugin/my/plugin")
+ .forceV2(true)
+ .withMethod(GET)
+ .build().process(cluster.getSolrClient()),
+ ImmutableMap.of("/testkey", "testval"));
+
+ new V2Request.Builder("/cluster/plugin")
+ .withMethod(POST)
+ .forceV2(true)
+ .withPayload("{remove : testplugin}")
+ .build()
+ .process(cluster.getSolrClient());
+
+ rsp = new V2Request.Builder("/cluster/plugin")
+ .forceV2(true)
+ .withMethod(GET)
+ .build()
+ .process(cluster.getSolrClient());
+ assertEquals(null, rsp._get("/plugin/testplugin/class", null));
+
+}
[GitHub] [lucene-solr] uschindler commented on a change in pull request #1522: LUCENE-9374: Add checkBrokenLinks gradle task
uschindler commented on a change in pull request #1522:
URL: https://github.com/apache/lucene-solr/pull/1522#discussion_r426408284
##
File path: gradle/validation/documentation-lint.gradle
##
@@ -0,0 +1,65 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+configure(rootProject) {
+
+ task documentationLint {
+group 'Verification'
+description 'Verify all documentation'
+
+dependsOn 'documentation'
+dependsOn subprojects.collect { prj ->
+ prj.tasks.matching { task -> task.name == 'checkBrokenLinks'}
+}
+ }
+
+ // TODO: uncomment this line after fixing all broken links.
+ // (we can't fix the cross-project links until ant build is disabled.)
+ // check.dependsOn documentationLint
+}
+
+configure(subprojects.findAll { it.path in [':lucene', ':solr'] }) {
+ task checkBrokenLinks(type: CheckBrokenLinksTask)
+}
+
+class CheckBrokenLinksTask extends DefaultTask {
+ @Input
+ File docsDir = project.docroot
Review comment:
See b7c60e53eb8d7c7c01ccd7c00add2662e503fd08
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9321) Port documentation task to gradle
[ https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17109954#comment-17109954 ] ASF subversion and git services commented on LUCENE-9321: - Commit b7c60e53eb8d7c7c01ccd7c00add2662e503fd08 in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b7c60e5 ] LUCENE-9321: Lazy evaluate project properties in the render-javadocs / changes2html task, also make URL (as its passed on command line) an input of task > Port documentation task to gradle > - > > Key: LUCENE-9321 > URL: https://issues.apache.org/jira/browse/LUCENE-9321 > Project: Lucene - Core > Issue Type: Sub-task > Components: general/build >Reporter: Tomoko Uchida >Assignee: Uwe Schindler >Priority: Major > Fix For: master (9.0) > > Attachments: screenshot-1.png > > Time Spent: 9h > Remaining Estimate: 0h > > This is a placeholder issue for porting ant "documentation" task to gradle. > The generated documents should be able to be published on lucene.apache.org > web site on "as-is" basis. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] dsmiley opened a new pull request #1524: SOLR-XXXX: Rewrite Hash query
dsmiley opened a new pull request #1524:
URL: https://github.com/apache/lucene-solr/pull/1524
* Simpler
* Don't use Filter (to be removed)
* Do use TwoPhaseIterator, not PostFilter
* Don't pre-compute matching docs (wasteful)
* Support more fields, and more field types
* Faster hash on Strings (avoid Char conversion)
* Stronger hash when using multiple fields
@joel-bernstein, I set out to remove the use of Filter in `{!hash}` (because
https://issues.apache.org/jira/browse/SOLR-12336 ) and then I saw a bunch of
things that I felt could be improved. Apparently I had nothing better to do
this weekend j/k WDYT?
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
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
