[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1600: SOLR Move "userfiles" stuff from SolrPaths to CoreContainer.
dsmiley commented on a change in pull request #1600:
URL: https://github.com/apache/lucene-solr/pull/1600#discussion_r444641471
##
File path: solr/core/src/java/org/apache/solr/handler/CatStream.java
##
@@ -158,28 +157,20 @@ public Explanation toExplanation(StreamFactory factory)
throws IOException {
}
private List validateAndSetFilepathsInSandbox() {
-final String[] relativePathRoots = commaDelimitedFilepaths.split(",");
-
final List crawlSeeds = new ArrayList<>();
-for (String crawlRoot : relativePathRoots) {
- final File crawlRootFile = new File(crawlRoot);
- if (crawlRootFile.isAbsolute()) {
-throw new SolrException(SolrException.ErrorCode.BAD_REQUEST,
-"file/directory to stream must be provided as an absolute path: "
+ crawlRoot);
- }
- if ( crawlRoot.contains("..")) {
+for (String crawlRootStr : commaDelimitedFilepaths.split(",")) {
+ Path crawlRootPath = chroot.resolve(crawlRootStr).normalize();
+ if (! crawlRootPath.startsWith(chroot)) {
Review comment:
Path "startsWith" API makes what you were trying to do simpler (less
code).
##
File path: solr/core/src/java/org/apache/solr/core/SolrPaths.java
##
@@ -94,26 +87,6 @@ public static Path locateSolrHome() {
return Paths.get(home).toAbsolutePath().normalize();
}
- public static void ensureUserFilesDataDir(Path solrHome) {
-final Path userFilesPath = getUserFilesPath(solrHome);
-final File userFilesDirectory = new File(userFilesPath.toString());
-if (!userFilesDirectory.exists()) {
Review comment:
The delta here with Paths API isn't line-for-line; it's much better.
`Files.createDirectories` works if it exists and simply throws if something
goes wrong.
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-14376) Optimize SolrIndexSearcher.getDocSet and getProcessedFilter for empty fq
[ https://issues.apache.org/jira/browse/SOLR-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143509#comment-17143509 ] David Smiley commented on SOLR-14376: - What you found there could be removed (the needless condition to check if filterQueries list is not empty) because it'll be cheap to go through this code path now. I also observe that it appears that "fq" defaults to null and so it's kinda moot but not completely since a query string can parse to nothing. > Optimize SolrIndexSearcher.getDocSet and getProcessedFilter for empty fq > > > Key: SOLR-14376 > URL: https://issues.apache.org/jira/browse/SOLR-14376 > Project: Solr > Issue Type: Improvement > Components: search >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: 8.6 > > Time Spent: 20m > Remaining Estimate: 0h > > If either SolrIndexSearcher.getDocSet or getProcessedFilter are called with > an null/empty query list, we should be able to short-circuit this with a > getLiveDocSet response. Today getDocSet builds up a new DocSet, bit by bit > :-/ -- 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-12698) SolrFeature: no-fq optimisation
[ https://issues.apache.org/jira/browse/SOLR-12698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143478#comment-17143478 ] David Smiley commented on SOLR-12698: - Looks like it :-) We can close as duplicate then. > SolrFeature: no-fq optimisation > --- > > Key: SOLR-12698 > URL: https://issues.apache.org/jira/browse/SOLR-12698 > Project: Solr > Issue Type: Sub-task > Components: contrib - LTR >Reporter: Stanislav Livotov >Priority: Major > Attachments: SOLR-12698.patch > > > [~slivotov] wrote in SOLR-12688: > bq. ... SolrFeature was not optimally implemented for the case when no fq > parameter was passed. I'm not absolutely sure what was the intention to > introduce both q(which is supposed to be a function query) and fq parameter > for the same SolrFeature at all(Is there a case when they will be used > together ? ), so I decided not to change behavior but just optimize described > case ... > (Please see SOLR-12688 description for overall context and analysis results.) -- 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] noblepaul commented on pull request #1432: SOLR-14404 CoreContainer level custom requesthandlers
noblepaul commented on pull request #1432: URL: https://github.com/apache/lucene-solr/pull/1432#issuecomment-648495409 @dsmiley Yes, I want all our components to be written using - Annotations (even our internal components) - All input output to use POJOs 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 #1598: SOLR-14409: Existing violations allow bypassing policy rules when add…
noblepaul commented on a change in pull request #1598:
URL: https://github.com/apache/lucene-solr/pull/1598#discussion_r444575124
##
File path:
solr/solrj/src/test/org/apache/solr/client/solrj/cloud/autoscaling/TestPolicy2.java
##
@@ -516,6 +517,16 @@ public void testInfiniteLoop() {
System.out.println(suggestions);
}
+ public void testAddTooManyPerPolicy() {
+Map m = (Map)
loadFromResource("testAddTooManyPerPolicy.json");
+SolrCloudManager cloudManagerFromDiagnostics =
createCloudManagerFromDiagnostics(m);
+AutoScalingConfig autoScalingConfig = new AutoScalingConfig((Map) getObjectByPath(m, false, "diagnostics/config"));
+SolrException exp = expectThrows(SolrException.class, () ->
PolicyHelper.getReplicaLocations("TooManyPerPolicy", autoScalingConfig,
cloudManagerFromDiagnostics,
+EMPTY_MAP, Collections.singletonList("shard1"), 1, 0, 0, null));
+assertTrue(exp.getMessage().contains("No node can satisfy the rules"));
Review comment:
what's the difference?
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-14590) Add support for FeatureField in Solr
Tomas Eduardo Fernandez Lobbe created SOLR-14590:
Summary: Add support for FeatureField in Solr
Key: SOLR-14590
URL: https://issues.apache.org/jira/browse/SOLR-14590
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomas Eduardo Fernandez Lobbe
{{FeatureField}}’s allow users to store scoring factors in the index that are
encoded as term frequencies. By doing this, {{FeatureFields}} can be used in
combination with the {{minExactCount}} parameter to skip over non-competitive
documents, and produce results faster. See LUCENE-8197
--
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-14589) Remove IntelliJ //noinspection comments
[ https://issues.apache.org/jira/browse/SOLR-14589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14589. --- Fix Version/s: 8.6 Resolution: Fixed > Remove IntelliJ //noinspection comments > --- > > Key: SOLR-14589 > URL: https://issues.apache.org/jira/browse/SOLR-14589 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.6 > > > We shouldn't have IDE-specific comments in the code. -- 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-14589) Remove IntelliJ //noinspection comments
[ https://issues.apache.org/jira/browse/SOLR-14589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143405#comment-17143405 ] Erick Erickson commented on SOLR-14589: --- Fat fingered the commit message, here are the SHAs Commit 85611f7ee5a654b04e4a6216ef9da76e95fd9088 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=85611f7 ] SOLR-14541: Remove IntelliJ //noinspection comments Commit db986086f53e3f7a936817b546edf46ee4548523 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=db98608 ] SOLR-14541: Remove IntelliJ //noinspection comments > Remove IntelliJ //noinspection comments > --- > > Key: SOLR-14589 > URL: https://issues.apache.org/jira/browse/SOLR-14589 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > We shouldn't have IDE-specific comments in the code. -- 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] [Issue Comment Deleted] (SOLR-14541) Ensure classes that implement equals implement hashCode or suppress warnings
[ https://issues.apache.org/jira/browse/SOLR-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-14541: -- Comment: was deleted (was: Commit 85611f7ee5a654b04e4a6216ef9da76e95fd9088 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=85611f7 ] SOLR-14541: Remove IntelliJ //noinspection comments ) > Ensure classes that implement equals implement hashCode or suppress warnings > > > Key: SOLR-14541 > URL: https://issues.apache.org/jira/browse/SOLR-14541 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: 0001-SOLR-14541-add-hashCode-for-some-classes.patch, > 0002-SOLR-14541-add-hashCode-for-some-classes-in-autoscal.patch, > 0003-SOLR-14541-add-hashCode-or-remove-equals-for-some-cl.patch > > Time Spent: 2h > Remaining Estimate: 0h > > While looking at warnings, I found that the following classes generate this > warning: > *overrides equals, but neither it nor any superclass overrides hashCode > method* > I can suppress the warning, but this has been a source of errors in the past > so I'm reluctant to just do that blindly. > NOTE: The Lucene one should probably be it's own Jira if it's going to have > hashCode implemented, but here for triage. > What I need for each method is for someone who has a clue about that > particular code to render an opinion that we can safely suppress the warning > or to provide a hashCode method. > Some of these have been here for a very long time and were implemented by > people no longer active... > lucene/suggest/src/java/org/apache/lucene/search/spell/LuceneLevenshteinDistance.java:39 > solr/solrj/src/java/org/apache/solr/common/cloud/ZkNodeProps.java:34 > solr/solrj/src/java/org/apache/solr/common/cloud/Replica.java:26 > solr/solrj/src/java/org/apache/solr/common/cloud/DocCollection.java:49 > solr/core/src/java/org/apache/solr/cloud/rule/Rule.java:277 > solr/core/src/java/org/apache/solr/pkg/PackageAPI.java:177 > solr/core/src/java/org/apache/solr/packagemanager/SolrPackageInstance.java:31 > > Noble Paul says it's OK to suppress warnings for these: > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/VersionedData.java:31 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:61 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:150 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:252 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:45 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Policy.java:73 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Preference.java:32 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaInfo.java:39 > > Joel Bernstein says it's OK to suppress warnings for these: > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaCount.java:27 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpression.java:25 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionNamedParameter.java:23 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/CloudSolrStream.java:467 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/DeepRandomStream.java:417 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionValue.java:22 > -- 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] [Issue Comment Deleted] (SOLR-14541) Ensure classes that implement equals implement hashCode or suppress warnings
[ https://issues.apache.org/jira/browse/SOLR-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-14541: -- Comment: was deleted (was: Commit db986086f53e3f7a936817b546edf46ee4548523 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=db98608 ] SOLR-14541: Remove IntelliJ //noinspection comments ) > Ensure classes that implement equals implement hashCode or suppress warnings > > > Key: SOLR-14541 > URL: https://issues.apache.org/jira/browse/SOLR-14541 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: 0001-SOLR-14541-add-hashCode-for-some-classes.patch, > 0002-SOLR-14541-add-hashCode-for-some-classes-in-autoscal.patch, > 0003-SOLR-14541-add-hashCode-or-remove-equals-for-some-cl.patch > > Time Spent: 2h > Remaining Estimate: 0h > > While looking at warnings, I found that the following classes generate this > warning: > *overrides equals, but neither it nor any superclass overrides hashCode > method* > I can suppress the warning, but this has been a source of errors in the past > so I'm reluctant to just do that blindly. > NOTE: The Lucene one should probably be it's own Jira if it's going to have > hashCode implemented, but here for triage. > What I need for each method is for someone who has a clue about that > particular code to render an opinion that we can safely suppress the warning > or to provide a hashCode method. > Some of these have been here for a very long time and were implemented by > people no longer active... > lucene/suggest/src/java/org/apache/lucene/search/spell/LuceneLevenshteinDistance.java:39 > solr/solrj/src/java/org/apache/solr/common/cloud/ZkNodeProps.java:34 > solr/solrj/src/java/org/apache/solr/common/cloud/Replica.java:26 > solr/solrj/src/java/org/apache/solr/common/cloud/DocCollection.java:49 > solr/core/src/java/org/apache/solr/cloud/rule/Rule.java:277 > solr/core/src/java/org/apache/solr/pkg/PackageAPI.java:177 > solr/core/src/java/org/apache/solr/packagemanager/SolrPackageInstance.java:31 > > Noble Paul says it's OK to suppress warnings for these: > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/VersionedData.java:31 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:61 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:150 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:252 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:45 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Policy.java:73 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Preference.java:32 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaInfo.java:39 > > Joel Bernstein says it's OK to suppress warnings for these: > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaCount.java:27 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpression.java:25 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionNamedParameter.java:23 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/CloudSolrStream.java:467 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/DeepRandomStream.java:417 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionValue.java:22 > -- 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-14541) Ensure classes that implement equals implement hashCode or suppress warnings
[ https://issues.apache.org/jira/browse/SOLR-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143404#comment-17143404 ] ASF subversion and git services commented on SOLR-14541: Commit db986086f53e3f7a936817b546edf46ee4548523 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=db98608 ] SOLR-14541: Remove IntelliJ //noinspection comments > Ensure classes that implement equals implement hashCode or suppress warnings > > > Key: SOLR-14541 > URL: https://issues.apache.org/jira/browse/SOLR-14541 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: 0001-SOLR-14541-add-hashCode-for-some-classes.patch, > 0002-SOLR-14541-add-hashCode-for-some-classes-in-autoscal.patch, > 0003-SOLR-14541-add-hashCode-or-remove-equals-for-some-cl.patch > > Time Spent: 2h > Remaining Estimate: 0h > > While looking at warnings, I found that the following classes generate this > warning: > *overrides equals, but neither it nor any superclass overrides hashCode > method* > I can suppress the warning, but this has been a source of errors in the past > so I'm reluctant to just do that blindly. > NOTE: The Lucene one should probably be it's own Jira if it's going to have > hashCode implemented, but here for triage. > What I need for each method is for someone who has a clue about that > particular code to render an opinion that we can safely suppress the warning > or to provide a hashCode method. > Some of these have been here for a very long time and were implemented by > people no longer active... > lucene/suggest/src/java/org/apache/lucene/search/spell/LuceneLevenshteinDistance.java:39 > solr/solrj/src/java/org/apache/solr/common/cloud/ZkNodeProps.java:34 > solr/solrj/src/java/org/apache/solr/common/cloud/Replica.java:26 > solr/solrj/src/java/org/apache/solr/common/cloud/DocCollection.java:49 > solr/core/src/java/org/apache/solr/cloud/rule/Rule.java:277 > solr/core/src/java/org/apache/solr/pkg/PackageAPI.java:177 > solr/core/src/java/org/apache/solr/packagemanager/SolrPackageInstance.java:31 > > Noble Paul says it's OK to suppress warnings for these: > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/VersionedData.java:31 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:61 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:150 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:252 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:45 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Policy.java:73 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Preference.java:32 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaInfo.java:39 > > Joel Bernstein says it's OK to suppress warnings for these: > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaCount.java:27 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpression.java:25 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionNamedParameter.java:23 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/CloudSolrStream.java:467 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/DeepRandomStream.java:417 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionValue.java:22 > -- 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-14541) Ensure classes that implement equals implement hashCode or suppress warnings
[ https://issues.apache.org/jira/browse/SOLR-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143403#comment-17143403 ] ASF subversion and git services commented on SOLR-14541: Commit 85611f7ee5a654b04e4a6216ef9da76e95fd9088 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=85611f7 ] SOLR-14541: Remove IntelliJ //noinspection comments > Ensure classes that implement equals implement hashCode or suppress warnings > > > Key: SOLR-14541 > URL: https://issues.apache.org/jira/browse/SOLR-14541 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: 0001-SOLR-14541-add-hashCode-for-some-classes.patch, > 0002-SOLR-14541-add-hashCode-for-some-classes-in-autoscal.patch, > 0003-SOLR-14541-add-hashCode-or-remove-equals-for-some-cl.patch > > Time Spent: 2h > Remaining Estimate: 0h > > While looking at warnings, I found that the following classes generate this > warning: > *overrides equals, but neither it nor any superclass overrides hashCode > method* > I can suppress the warning, but this has been a source of errors in the past > so I'm reluctant to just do that blindly. > NOTE: The Lucene one should probably be it's own Jira if it's going to have > hashCode implemented, but here for triage. > What I need for each method is for someone who has a clue about that > particular code to render an opinion that we can safely suppress the warning > or to provide a hashCode method. > Some of these have been here for a very long time and were implemented by > people no longer active... > lucene/suggest/src/java/org/apache/lucene/search/spell/LuceneLevenshteinDistance.java:39 > solr/solrj/src/java/org/apache/solr/common/cloud/ZkNodeProps.java:34 > solr/solrj/src/java/org/apache/solr/common/cloud/Replica.java:26 > solr/solrj/src/java/org/apache/solr/common/cloud/DocCollection.java:49 > solr/core/src/java/org/apache/solr/cloud/rule/Rule.java:277 > solr/core/src/java/org/apache/solr/pkg/PackageAPI.java:177 > solr/core/src/java/org/apache/solr/packagemanager/SolrPackageInstance.java:31 > > Noble Paul says it's OK to suppress warnings for these: > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/VersionedData.java:31 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:61 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:150 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:252 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/AutoScalingConfig.java:45 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Policy.java:73 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/Preference.java:32 > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaInfo.java:39 > > Joel Bernstein says it's OK to suppress warnings for these: > > solr/solrj/src/java/org/apache/solr/client/solrj/cloud/autoscaling/ReplicaCount.java:27 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpression.java:25 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionNamedParameter.java:23 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/CloudSolrStream.java:467 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/DeepRandomStream.java:417 > > solr/solrj/src/java/org/apache/solr/client/solrj/io/stream/expr/StreamExpressionValue.java:22 > -- 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] [Created] (SOLR-14589) Remove IntelliJ //noinspection comments
Erick Erickson created SOLR-14589: - Summary: Remove IntelliJ //noinspection comments Key: SOLR-14589 URL: https://issues.apache.org/jira/browse/SOLR-14589 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Reporter: Erick Erickson Assignee: Erick Erickson We shouldn't have IDE-specific comments in the code. -- 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-11973) Fail compilation on warnings
[ https://issues.apache.org/jira/browse/SOLR-11973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-11973. --- Resolution: Fixed > Fail compilation on warnings > > > Key: SOLR-11973 > URL: https://issues.apache.org/jira/browse/SOLR-11973 > Project: Solr > Issue Type: Improvement > Components: Build >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > > Not quite sure whether this qualifies as something for Solr or Lucene > I'm working gradually on getting precommit lint warnings out of the code > base. I'd like to selectively fail a subtree once it's clean. I played around > a bit with Robert's suggestions on the dev list but couldn't quite get it to > work, then decided I needed to focus on one thing at a time. > See SOLR-10809 for the first clean directory Real Soon Now. > Bonus points would be working out how to fail on deprecation warnings when > building Solr too, although that's farther off in the future. > Assigning to myself, but anyone who knows the build ins and outs _please_ > feel free to take 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] [Resolved] (SOLR-14534) Investigate cleaning up any remaining warnings in 8x
[ https://issues.apache.org/jira/browse/SOLR-14534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-14534. --- Resolution: Won't Fix At this point, 8x only has warnings in Lucene since LUCENE-9394 wasn't backported due to back-compat concerns. Since I gave up on having the compilations break if warnings were present under Ant (See LUCENE-9411, and since we don't build with Gradle on 8x, I don't think there's any good purpose to be served by having the code diverge any more. > Investigate cleaning up any remaining warnings in 8x > > > Key: SOLR-14534 > URL: https://issues.apache.org/jira/browse/SOLR-14534 > Project: Solr > Issue Type: Sub-task >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > > There will be some divergence between master and 8x. The current pattern is > 1> clean up warnings in master > 2> backport to 8x and insure all tests etc run. > Conspicuously missing is compiling under 8x and insuring that there are no > warnings in the cleaned code. > I'm not sure I really will do this if it turns out there are a lot of them. > It's good enough that master is (and stay) clean IMO. OTOH, if it only takes > a short time. Won't be able to tell until we get code clean. -- 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] megancarey commented on a change in pull request #1592: SOLR-14579 First pass at dismantling Utils
megancarey commented on a change in pull request #1592: URL: https://github.com/apache/lucene-solr/pull/1592#discussion_r444544150 ## File path: solr/core/src/java/org/apache/solr/cloud/autoscaling/AutoScalingHandler.java ## @@ -542,7 +542,7 @@ private AutoScalingConfig handleSetTrigger(SolrQueryRequest req, SolrQueryRespon String eventTypeStr = op.getStr(EVENT); if (op.hasError()) return currentConfig; -TriggerEventType eventType = TriggerEventType.valueOf(eventTypeStr.trim().toUpperCase(Locale.ROOT)); +TriggerEventType.valueOf(eventTypeStr.trim().toUpperCase(Locale.ROOT)); Review comment: If the eventTypeStr is an invalid event type, it will throw an exception that there are no matches in TriggerEventType enum. I'll add a comment so the reason for this line is more obvious. 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-12698) SolrFeature: no-fq optimisation
[
https://issues.apache.org/jira/browse/SOLR-12698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143301#comment-17143301
]
Lucene/Solr QA commented on SOLR-12698:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 8s{color}
| {color:red} SOLR-12698 does not apply to master. Rebase required? Wrong
Branch? See
https://wiki.apache.org/solr/HowToContribute#Creating_the_patch_file for help.
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | SOLR-12698 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12937795/SOLR-12698.patch |
| Console output |
https://builds.apache.org/job/PreCommit-SOLR-Build/767/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> SolrFeature: no-fq optimisation
> ---
>
> Key: SOLR-12698
> URL: https://issues.apache.org/jira/browse/SOLR-12698
> Project: Solr
> Issue Type: Sub-task
> Components: contrib - LTR
>Reporter: Stanislav Livotov
>Priority: Major
> Attachments: SOLR-12698.patch
>
>
> [~slivotov] wrote in SOLR-12688:
> bq. ... SolrFeature was not optimally implemented for the case when no fq
> parameter was passed. I'm not absolutely sure what was the intention to
> introduce both q(which is supposed to be a function query) and fq parameter
> for the same SolrFeature at all(Is there a case when they will be used
> together ? ), so I decided not to change behavior but just optimize described
> case ...
> (Please see SOLR-12688 description for overall context and analysis results.)
--
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] (LUCENE-9411) Fail complation on warnings, 9x gradle-only
[ https://issues.apache.org/jira/browse/LUCENE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved LUCENE-9411. Fix Version/s: master (9.0) Resolution: Fixed with the minor caveat that I backported some SuppressWarnings to 8x. > Fail complation on warnings, 9x gradle-only > --- > > Key: LUCENE-9411 > URL: https://issues.apache.org/jira/browse/LUCENE-9411 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Labels: build > Fix For: master (9.0) > > Attachments: LUCENE-9411.patch, LUCENE-9411.patch, LUCENE-9411.patch, > LUCENE-9411.patch, annotations-warnings.patch > > > Moving this over here from SOLR-11973 since it's part of the build system and > affects Lucene as well as Solr. You might want to see the discussion there. > We have a clean compile for both Solr and Lucene, no rawtypes, unchecked, > try, etc. warnings. There are some peculiar warnings (things like > SuppressFBWarnings, i.e. FindBugs) that I'm not sure about at all, but let's > assume those are not a problem. Now I'd like to start failing the compilation > if people write new code that generates warnings. > From what I can tell, just adding the flag is easy in both the Gradle and Ant > builds. I still have to prove out that adding -Werrors does what I expect, > i.e. succeeds now and fails when I introduce warnings. > But let's assume that works. Are there objections to this idea generally? I > hope to have some data by next Monday. > FWIW, the Lucene code base had far fewer issues than Solr, but > common-build.xml is in Lucene. -- 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-8962) Can we merge small segments during refresh, for faster searching?
[
https://issues.apache.org/jira/browse/LUCENE-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143295#comment-17143295
]
Michael McCandless commented on LUCENE-8962:
Thanks [~simonw], what a delightful unit test! Clearly it confirms what we
thought – the feature as implemented now breaks the atomicity guarantee of
{{updateDocument}} which is clearly no good! And I think this is likely tricky
to fix, if we need new locking around IW acquiring merge readers to ensure a
concurrent {{updateDocument}} is atomic with respect to that. Let's mull/sleep
on it ...
> Can we merge small segments during refresh, for faster searching?
> -
>
> Key: LUCENE-8962
> URL: https://issues.apache.org/jira/browse/LUCENE-8962
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
>Reporter: Michael McCandless
>Priority: Major
> Fix For: 8.6
>
> Attachments: LUCENE-8962_demo.png, failed-tests.patch,
> failure_log.txt, test.diff
>
> Time Spent: 19h 40m
> Remaining Estimate: 0h
>
> With near-real-time search we ask {{IndexWriter}} to write all in-memory
> segments to disk and open an {{IndexReader}} to search them, and this is
> typically a quick operation.
> However, when you use many threads for concurrent indexing, {{IndexWriter}}
> will accumulate write many small segments during {{refresh}} and this then
> adds search-time cost as searching must visit all of these tiny segments.
> The merge policy would normally quickly coalesce these small segments if
> given a little time ... so, could we somehow improve {{IndexWriter'}}s
> refresh to optionally kick off merge policy to merge segments below some
> threshold before opening the near-real-time reader? It'd be a bit tricky
> because while we are waiting for merges, indexing may continue, and new
> segments may be flushed, but those new segments shouldn't be included in the
> point-in-time segments returned by refresh ...
> One could almost do this on top of Lucene today, with a custom merge policy,
> and some hackity logic to have the merge policy target small segments just
> written by refresh, but it's tricky to then open a near-real-time reader,
> excluding newly flushed but including newly merged segments since the refresh
> originally finished ...
> I'm not yet sure how best to solve this, so I wanted to open an issue for
> 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] (LUCENE-9411) Fail complation on warnings, 9x gradle-only
[ https://issues.apache.org/jira/browse/LUCENE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143274#comment-17143274 ] ASF subversion and git services commented on LUCENE-9411: - Commit 9c1772f0946f2a2b2424caf09283b8add4770095 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9c1772f ] LUCENE-9411: Fail complation on warnings, 9x gradle-only > Fail complation on warnings, 9x gradle-only > --- > > Key: LUCENE-9411 > URL: https://issues.apache.org/jira/browse/LUCENE-9411 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Labels: build > Attachments: LUCENE-9411.patch, LUCENE-9411.patch, LUCENE-9411.patch, > LUCENE-9411.patch, annotations-warnings.patch > > > Moving this over here from SOLR-11973 since it's part of the build system and > affects Lucene as well as Solr. You might want to see the discussion there. > We have a clean compile for both Solr and Lucene, no rawtypes, unchecked, > try, etc. warnings. There are some peculiar warnings (things like > SuppressFBWarnings, i.e. FindBugs) that I'm not sure about at all, but let's > assume those are not a problem. Now I'd like to start failing the compilation > if people write new code that generates warnings. > From what I can tell, just adding the flag is easy in both the Gradle and Ant > builds. I still have to prove out that adding -Werrors does what I expect, > i.e. succeeds now and fails when I introduce warnings. > But let's assume that works. Are there objections to this idea generally? I > hope to have some data by next Monday. > FWIW, the Lucene code base had far fewer issues than Solr, but > common-build.xml is in Lucene. -- 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-9411) Fail complation on warnings, 9x gradle-only
[ https://issues.apache.org/jira/browse/LUCENE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143273#comment-17143273 ] ASF subversion and git services commented on LUCENE-9411: - Commit 8f9c774691ea6678c3855dd49d8d07cd06121973 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=8f9c774 ] LUCENE-9411: Fail complation on warnings, 9x gradle-only > Fail complation on warnings, 9x gradle-only > --- > > Key: LUCENE-9411 > URL: https://issues.apache.org/jira/browse/LUCENE-9411 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Labels: build > Attachments: LUCENE-9411.patch, LUCENE-9411.patch, LUCENE-9411.patch, > LUCENE-9411.patch, annotations-warnings.patch > > > Moving this over here from SOLR-11973 since it's part of the build system and > affects Lucene as well as Solr. You might want to see the discussion there. > We have a clean compile for both Solr and Lucene, no rawtypes, unchecked, > try, etc. warnings. There are some peculiar warnings (things like > SuppressFBWarnings, i.e. FindBugs) that I'm not sure about at all, but let's > assume those are not a problem. Now I'd like to start failing the compilation > if people write new code that generates warnings. > From what I can tell, just adding the flag is easy in both the Gradle and Ant > builds. I still have to prove out that adding -Werrors does what I expect, > i.e. succeeds now and fails when I introduce warnings. > But let's assume that works. Are there objections to this idea generally? I > hope to have some data by next Monday. > FWIW, the Lucene code base had far fewer issues than Solr, but > common-build.xml is in Lucene. -- 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] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143261#comment-17143261
]
BARIS KAZAR edited comment on LUCENE-9221 at 6/23/20, 8:10 PM:
---
Ryan,
Thanks, i hope folks like them.
Can voters please assume Apache is attached with same font type and same
or smaller size?
Thanks
baris
was (Author: bkazar):
Ryan,
Can voters please assume Apache is attached with same font type and same
or smaller size?
Thanks
baris
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, lucene_logo6.pdf, lucene_logo7.pdf,
> lucene_logo8.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143261#comment-17143261
]
BARIS KAZAR edited comment on LUCENE-9221 at 6/23/20, 8:08 PM:
---
Ryan,
Can voters please assume Apache is attached with same font type and same
or smaller size?
Thanks
baris
was (Author: bkazar):
Ryan,
Can voters please assume Apache is attached with same font type and same
or smaller size?
i can place a note to my submissions.
Thanks
baris
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, lucene_logo6.pdf, lucene_logo7.pdf,
> lucene_logo8.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143263#comment-17143263
]
BARIS KAZAR commented on LUCENE-9221:
-
Can voters please assume Apache is attached with same font type and same or
smaller size for my submissions with Lucene_logo*.pdf?
Thanks
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, lucene_logo6.pdf, lucene_logo7.pdf,
> lucene_logo8.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143261#comment-17143261
]
BARIS KAZAR commented on LUCENE-9221:
-
Ryan,
Can voters please assume Apache is attached with same font type and same
or smaller size?
i can place a note to my submissions.
Thanks
baris
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, lucene_logo6.pdf, lucene_logo7.pdf,
> lucene_logo8.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-9280) Add ability to skip non-competitive documents on field sort
[ https://issues.apache.org/jira/browse/LUCENE-9280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143257#comment-17143257 ] ASF subversion and git services commented on LUCENE-9280: - Commit b0333ab5c8de3df0c0d781f01c1f6c8e7f12be71 in lucene-solr's branch refs/heads/master from Mayya Sharipova [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b0333ab ] LUCENE-9280: Collectors to skip noncompetitive documents (#1351) Similar how scorers can update their iterators to skip non-competitive documents, collectors and comparators should also provide and update iterators that allow them to skip non-competive documents. > Add ability to skip non-competitive documents on field sort > > > Key: LUCENE-9280 > URL: https://issues.apache.org/jira/browse/LUCENE-9280 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Mayya Sharipova >Priority: Minor > Time Spent: 18h 10m > Remaining Estimate: 0h > > Today collectors, once they collect enough docs, can instruct scorers to > update their iterators to skip non-competitive documents. This is applicable > only for a case when we need top docs by _score. > It would be nice to also have an ability to skip non-competitive docs when we > need top docs sorted by other fields different from _score. -- 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] mayya-sharipova merged pull request #1351: LUCENE-9280: Collectors to skip noncompetitive documents
mayya-sharipova merged pull request #1351: URL: https://github.com/apache/lucene-solr/pull/1351 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-13268) Clean up any test failures resulting from defaulting to async logging
[ https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-13268. --- Fix Version/s: 8.6 Resolution: Fixed I'm calling this "fixed" because any future errors won't be because of async logging in tests, unless the tests somehow use the production log4j configs. In which case we need a new JIRA. > Clean up any test failures resulting from defaulting to async logging > - > > Key: SOLR-13268 > URL: https://issues.apache.org/jira/browse/SOLR-13268 > Project: Solr > Issue Type: Bug >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Fix For: 8.6 > > Attachments: SOLR-13268-flushing.patch, SOLR-13268.patch, > SOLR-13268.patch, SOLR-13268.patch > > Time Spent: 1h > Remaining Estimate: 0h > > This is a catch-all for test failures due to the async logging changes. So > far, the I see a couple failures on JDK13 only. I'll collect a "starter set" > here, these are likely systemic, once the root cause is found/fixed, then > others are likely fixed as well. > JDK13: > ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV > -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk > -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 -- 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-13268) Clean up any test failures resulting from defaulting to async logging
[ https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143249#comment-17143249 ] ASF subversion and git services commented on SOLR-13268: Commit ea1bb9f2e963af17631640140f6fcb56f8ef0937 in lucene-solr's branch refs/heads/master from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ea1bb9f ] SOLR-13268: Clean up any test failures resulting from defaulting to async logging > Clean up any test failures resulting from defaulting to async logging > - > > Key: SOLR-13268 > URL: https://issues.apache.org/jira/browse/SOLR-13268 > Project: Solr > Issue Type: Bug >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13268-flushing.patch, SOLR-13268.patch, > SOLR-13268.patch, SOLR-13268.patch > > Time Spent: 1h > Remaining Estimate: 0h > > This is a catch-all for test failures due to the async logging changes. So > far, the I see a couple failures on JDK13 only. I'll collect a "starter set" > here, these are likely systemic, once the root cause is found/fixed, then > others are likely fixed as well. > JDK13: > ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV > -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk > -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 -- 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-13268) Clean up any test failures resulting from defaulting to async logging
[ https://issues.apache.org/jira/browse/SOLR-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143248#comment-17143248 ] ASF subversion and git services commented on SOLR-13268: Commit de555f2656c8af8deb71a7341dd4111c4d9596f1 in lucene-solr's branch refs/heads/branch_8x from Erick Erickson [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=de555f2 ] SOLR-13268: Clean up any test failures resulting from defaulting to async logging > Clean up any test failures resulting from defaulting to async logging > - > > Key: SOLR-13268 > URL: https://issues.apache.org/jira/browse/SOLR-13268 > Project: Solr > Issue Type: Bug >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Attachments: SOLR-13268-flushing.patch, SOLR-13268.patch, > SOLR-13268.patch, SOLR-13268.patch > > Time Spent: 1h > Remaining Estimate: 0h > > This is a catch-all for test failures due to the async logging changes. So > far, the I see a couple failures on JDK13 only. I'll collect a "starter set" > here, these are likely systemic, once the root cause is found/fixed, then > others are likely fixed as well. > JDK13: > ant test -Dtestcase=TestJmxIntegration -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=lv-LV > -Dtests.timezone=Asia/Riyadh -Dtests.asserts=true -Dtests.file.encoding=UTF-8 > ant test -Dtestcase=TestDynamicURP -Dtests.seed=54B30AC62A2D71E > -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=rwk > -Dtests.timezone=Australia/Brisbane -Dtests.asserts=true > -Dtests.file.encoding=UTF-8 -- 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] anshumg commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
anshumg commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r55004
##
File path: solr/core/src/java/org/apache/solr/core/SolrCore.java
##
@@ -1164,6 +1171,16 @@ private SolrCoreMetricManager
initCoreMetricManager(SolrConfig config) {
return coreMetricManager;
}
+ private CircuitBreakerManager initCircuitBreakerManager() {
+CircuitBreakerManager circuitBreakerManager = new CircuitBreakerManager();
+
+// Install the default circuit breakers
+CircuitBreaker memoryCircuitBreaker = new MemoryCircuitBreaker(this);
+circuitBreakerManager.registerCircuitBreaker(CircuitBreakerType.MEMORY,
memoryCircuitBreaker);
Review comment:
I was thinking of moving this outside of SolrCore, so custom Circuit
breakers could be implemented and plugged without any change to SolrCore? What
do you think?
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] anshumg commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
anshumg commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r53638
##
File path: solr/core/src/java/org/apache/solr/core/SolrConfig.java
##
@@ -224,6 +224,13 @@ private SolrConfig(SolrResourceLoader loader, String name,
boolean isConfigsetTr
queryResultWindowSize = Math.max(1, getInt("query/queryResultWindowSize",
1));
queryResultMaxDocsCached = getInt("query/queryResultMaxDocsCached",
Integer.MAX_VALUE);
enableLazyFieldLoading = getBool("query/enableLazyFieldLoading", false);
+
+useCircuitBreakers = getBool("query/useCircuitBreakers", false);
+memoryCircuitBreakerThreshold =
getInt("query/memoryCircuitBreakerThreshold", 100);
+
+if (memoryCircuitBreakerThreshold > 100 || memoryCircuitBreakerThreshold <
0) {
Review comment:
Perhaps you want to change this to early saying "Circuit breaker
disabled, but incorrectly configured" or conditionally?
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] atris commented on pull request #1606: SOLR-14588: Implement Circuit Breakers
atris commented on pull request #1606: URL: https://github.com/apache/lucene-solr/pull/1606#issuecomment-648362568 @madrob Updated, please see and share your thoughts. 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] atris commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r44004
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/MemoryCircuitBreaker.java
##
@@ -0,0 +1,88 @@
+/*
+ * 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.util.circuitbreaker;
+
+import java.lang.management.ManagementFactory;
+import java.lang.management.MemoryMXBean;
+
+import org.apache.solr.core.SolrCore;
+
+public class MemoryCircuitBreaker extends CircuitBreaker {
+ private static final MemoryMXBean MEMORY_MX_BEAN =
ManagementFactory.getMemoryMXBean();
+
+ // Assumption -- the value of these parameters will be set correctly before
invoking printDebugInfo()
+ private double seenMemory;
+ private double allowedMemory;
+
+ public MemoryCircuitBreaker(SolrCore solrCore) {
+super(solrCore);
+ }
+
+ // TODO: An optimization can be to trip the circuit breaker for a duration
of time
+ // after the circuit breaker condition is matched. This will optimize for
per call
+ // overhead of calculating the condition parameters but can result in false
positives.
+ @Override
+ public boolean isCircuitBreakerGauntletTripped() {
+if (!isCircuitBreakerEnabled()) {
+ return false;
+}
+
+allowedMemory = getCurrentMemoryThreshold();
+
+if (allowedMemory < 0) {
+ // No threshold
+ return false;
+}
+
+seenMemory = calculateLiveMemoryUsage();
+
+return (seenMemory >= allowedMemory);
+ }
+
+ @Override
+ public String printDebugInfo() {
+return "seen memory " + seenMemory + " allowed memory " + allowedMemory;
+ }
+
+ private double getCurrentMemoryThreshold() {
+int thresholdValueInPercentage =
solrCore.getSolrConfig().memoryCircuitBreakerThreshold;
+long currentMaxHeap = MEMORY_MX_BEAN.getHeapMemoryUsage().getMax();
+
+if (currentMaxHeap <= 0) {
+ return Long.MIN_VALUE;
+}
+
+double thresholdInFraction = (double) thresholdValueInPercentage / 100;
+double actualLimit = currentMaxHeap * thresholdInFraction;
+
+if (actualLimit <= 0) {
+ throw new IllegalStateException("Memory limit cannot be less than or
equal to zero");
+}
+
+return actualLimit;
+ }
+
+ /**
+ * Calculate the live memory usage for the system. This method has package
visibility
+ * to allow using for testing
+ * @return Memory usage in bytes
+ */
+ protected long calculateLiveMemoryUsage() {
+return MEMORY_MX_BEAN.getHeapMemoryUsage().getUsed();
Review comment:
Yes, I considered MemoryUsageGaugeSet and did not use it for the precise
reason that you described. To be honest, the listener based implementation is
harder to read than the current, and I was not sure if it is worth going that
route for shaving off < 100 ns per query. However, if you have concerns or if
we ever hear slowness reports due to this feature, I am happy to take that
route. For now, I have added the comment as suggested, thanks.
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-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143212#comment-17143212
]
Ryan Ernst commented on LUCENE-9221:
[~bkazar] thanks for the submissions! Please take note of the contest
instructions, particularly regarding guidelines from Apache on logos:
{noformat}
The logo should adhere to the guidelines set forth by Apache for project logos
(https://www.apache.org/foundation/marks/pmcs#graphics), specifically that the
full project name, "Apache Lucene", must appear in the logo (although the word
"Apache" may be in a smaller font than "Lucene").
{noformat}
It looks like all of your submissions only contain the word Lucene. They would
need to include "Apache Lucene" to be valid submissions.
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, lucene_logo6.pdf, lucene_logo7.pdf,
> lucene_logo8.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143205#comment-17143205
]
BARIS KAZAR commented on LUCENE-9221:
-
Lucene Logo 8 [^lucene_logo8.pdf]
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, lucene_logo6.pdf, lucene_logo7.pdf,
> lucene_logo8.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BARIS KAZAR updated LUCENE-9221:
Attachment: lucene_logo8.pdf
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, lucene_logo6.pdf, lucene_logo7.pdf,
> lucene_logo8.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143202#comment-17143202
]
BARIS KAZAR commented on LUCENE-9221:
-
Lucene Logo 6 [^lucene_logo6.pdf]
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, lucene_logo6.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143203#comment-17143203
]
BARIS KAZAR commented on LUCENE-9221:
-
Lucene Logo 7 [^lucene_logo7.pdf]
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, lucene_logo6.pdf, lucene_logo7.pdf,
> zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BARIS KAZAR updated LUCENE-9221:
Attachment: lucene_logo7.pdf
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, lucene_logo6.pdf, lucene_logo7.pdf,
> zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BARIS KAZAR updated LUCENE-9221:
Attachment: lucene_logo6.pdf
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, lucene_logo6.pdf, lucene_logo7.pdf,
> zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BARIS KAZAR updated LUCENE-9221:
Attachment: lucene_logo5.pdf
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143199#comment-17143199
]
BARIS KAZAR commented on LUCENE-9221:
-
Lucene Logo 4 [^lucene_logo4.pdf]
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143200#comment-17143200
]
BARIS KAZAR commented on LUCENE-9221:
-
Lucene Logo 5 [^lucene_logo5.pdf]
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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] atris commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r24345
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/MemoryCircuitBreaker.java
##
@@ -0,0 +1,89 @@
+/*
+ * 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.util.circuitbreaker;
+
+import java.lang.management.ManagementFactory;
+import java.lang.management.MemoryMXBean;
+
+import org.apache.solr.core.SolrCore;
+
+public class MemoryCircuitBreaker extends CircuitBreaker {
+ private static final MemoryMXBean MEMORY_MX_BEAN =
ManagementFactory.getMemoryMXBean();
+
+ private final long currentMaxHeap =
MEMORY_MX_BEAN.getHeapMemoryUsage().getMax();
+
+ // Assumption -- the value of these parameters will be set correctly before
invoking printDebugInfo()
+ private double seenMemory;
+ private double allowedMemory;
+
+ public MemoryCircuitBreaker(SolrCore solrCore) {
+super(solrCore);
+ }
+
+ // TODO: An optimization can be to trip the circuit breaker for a duration
of time
+ // after the circuit breaker condition is matched. This will optimize for
per call
+ // overhead of calculating the condition parameters but can result in false
positives.
+ @Override
+ public boolean isCircuitBreakerGauntletTripped() {
+if (!isCircuitBreakerEnabled()) {
+ return false;
+}
+
+allowedMemory = getCurrentMemoryThreshold();
+
+if (allowedMemory < 0) {
Review comment:
Another of my overtly cautious safety nets :) Removed, thanks.
##
File path: solr/core/src/java/org/apache/solr/core/SolrConfig.java
##
@@ -224,6 +224,13 @@ private SolrConfig(SolrResourceLoader loader, String name,
boolean isConfigsetTr
queryResultWindowSize = Math.max(1, getInt("query/queryResultWindowSize",
1));
queryResultMaxDocsCached = getInt("query/queryResultMaxDocsCached",
Integer.MAX_VALUE);
enableLazyFieldLoading = getBool("query/enableLazyFieldLoading", false);
+
+useCircuitBreakers = getBool("query/useCircuitBreakers", false);
+memoryCircuitBreakerThreshold =
getInt("query/memoryCircuitBreakerThreshold", 100);
+
+if (memoryCircuitBreakerThreshold > 100 || memoryCircuitBreakerThreshold <
0) {
Review comment:
I was being overtly cautious here -- it seems wrong if the parameter is
incorrectly specified regardless of whether it is used or not?
##
File path: solr/core/src/test/org/apache/solr/util/TestCircuitBreaker.java
##
@@ -0,0 +1,191 @@
+/*
+ * 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.util;
+
+import java.io.IOException;
+import java.util.HashMap;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import org.apache.lucene.util.NamedThreadFactory;
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.params.CommonParams;
+import org.apache.solr.common.util.ExecutorUtil;
+import org.apache.solr.common.util.SolrNamedThreadFactory;
+import org.apache.solr.core.SolrCore;
+import org.apache.solr.search.QueryParsing;
+import org.apache.solr.util.circuitbreaker.CircuitBreaker;
+import org.apache.solr.util.circuitbreaker.CircuitBreakerType;
+import org.apache.solr.util.circuitbreaker.MemoryCircuitBreaker;
+import org.junit.AfterClass;
[jira] [Commented] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143195#comment-17143195
]
BARIS KAZAR commented on LUCENE-9221:
-
Lucene Logo 3 [^lucene_logo3.pdf]
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BARIS KAZAR updated LUCENE-9221:
Attachment: lucene_logo4.pdf
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> lucene_logo4.pdf, lucene_logo5.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143197#comment-17143197
]
BARIS KAZAR commented on LUCENE-9221:
-
Lucene Logo 3.1 [^lucene_logo3_1.pdf]
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BARIS KAZAR updated LUCENE-9221:
Attachment: lucene_logo3.pdf
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BARIS KAZAR updated LUCENE-9221:
Attachment: lucene_logo3_1.pdf
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, lucene_logo3.pdf, lucene_logo3_1.pdf,
> zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143193#comment-17143193
]
BARIS KAZAR commented on LUCENE-9221:
-
Lucene Logo2 [^lucene_logo2.pdf]
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BARIS KAZAR updated LUCENE-9221:
Attachment: lucene_logo2.pdf
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, lucene_logo2.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143189#comment-17143189
]
BARIS KAZAR commented on LUCENE-9221:
-
Lucene Logo 1[^lucene_logo1.pdf]
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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] (LUCENE-9221) Lucene Logo Contest
[
https://issues.apache.org/jira/browse/LUCENE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BARIS KAZAR updated LUCENE-9221:
Attachment: lucene_logo1.pdf
> Lucene Logo Contest
> ---
>
> Key: LUCENE-9221
> URL: https://issues.apache.org/jira/browse/LUCENE-9221
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ryan Ernst
>Priority: Trivial
> Attachments: LuceneLogo.png, Screen Shot 2020-04-10 at 8.29.32
> AM.png, image-2020-04-10-07-04-00-267.png, image.png, lucene-invert-a.png,
> lucene_logo1.pdf, zabetak-1-7.pdf
>
>
> The Lucene logo has served the project well for almost 20 years. However, it
> does sometimes show its age and misses modern nice-to-haves like invertable
> or grayscale variants.
>
> The PMC would like to have a contest to replace the current logo. This issue
> will serve as the submission mechanism for that contest. When the submission
> deadline closes, a community poll will be used to guide the PMC in the
> decision of which logo to choose. Keeping the current logo will be a possible
> outcome of this decision, if a majority likes the current logo more than any
> other proposal.
>
> The logo should adhere to the guidelines set forth by Apache for project
> logos ([https://www.apache.org/foundation/marks/pmcs#graphics]), specifically
> that the full project name, "Apache Lucene", must appear in the logo
> (although the word "Apache" may be in a smaller font than "Lucene").
>
> The contest will last approximately one month. The submission deadline is
> -*Monday, March 16, 2020*- *Monday, April 6, 2020*. Submissions should be
> attached in a single zip or tar archive, with the filename of the form
> {{[user]-[proposal number].[extension]}}.
--
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-12823) remove clusterstate.json in Lucene/Solr 9.0
[
https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143179#comment-17143179
]
Cassandra Targett edited comment on SOLR-12823 at 6/23/20, 6:20 PM:
Yes, because unseen in GitHub's rendering of the page is that there is a
comment under the 9.0 section heading that says: {{// DEVS: please put 9.0
Upgrade Notes in `major-changes-in-solr-9.adoc`!.}}, so when someone tries to
put anything there they will know not to.
was (Author: ctargett):
Yes, because unseen in GitHub's rendering of the page is that there is a
comment under it that says: {{// DEVS: please put 9.0 Upgrade Notes in
`major-changes-in-solr-9.adoc`!.}}, so when someone tries to put anything there
they will know not to.
> remove clusterstate.json in Lucene/Solr 9.0
> ---
>
> Key: SOLR-12823
> URL: https://issues.apache.org/jira/browse/SOLR-12823
> Project: Solr
> Issue Type: Task
>Reporter: Varun Thacker
>Assignee: Ilan Ginzburg
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove
> that in 9.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 9.0
[
https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143179#comment-17143179
]
Cassandra Targett commented on SOLR-12823:
--
Yes, because unseen in GitHub's rendering of the page is that there is a
comment under it that says: {{// DEVS: please put 9.0 Upgrade Notes in
`major-changes-in-solr-9.adoc`!.}}, so when someone tries to put anything there
they will know not to.
> remove clusterstate.json in Lucene/Solr 9.0
> ---
>
> Key: SOLR-12823
> URL: https://issues.apache.org/jira/browse/SOLR-12823
> Project: Solr
> Issue Type: Task
>Reporter: Varun Thacker
>Assignee: Ilan Ginzburg
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove
> that in 9.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] madrob commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
madrob commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r17940
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/MemoryCircuitBreaker.java
##
@@ -0,0 +1,89 @@
+/*
+ * 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.util.circuitbreaker;
+
+import java.lang.management.ManagementFactory;
+import java.lang.management.MemoryMXBean;
+
+import org.apache.solr.core.SolrCore;
+
+public class MemoryCircuitBreaker extends CircuitBreaker {
+ private static final MemoryMXBean MEMORY_MX_BEAN =
ManagementFactory.getMemoryMXBean();
+
+ private final long currentMaxHeap =
MEMORY_MX_BEAN.getHeapMemoryUsage().getMax();
+
+ // Assumption -- the value of these parameters will be set correctly before
invoking printDebugInfo()
+ private double seenMemory;
+ private double allowedMemory;
+
+ public MemoryCircuitBreaker(SolrCore solrCore) {
+super(solrCore);
+ }
+
+ // TODO: An optimization can be to trip the circuit breaker for a duration
of time
+ // after the circuit breaker condition is matched. This will optimize for
per call
+ // overhead of calculating the condition parameters but can result in false
positives.
+ @Override
+ public boolean isCircuitBreakerGauntletTripped() {
+if (!isCircuitBreakerEnabled()) {
+ return false;
+}
+
+allowedMemory = getCurrentMemoryThreshold();
+
+if (allowedMemory < 0) {
Review comment:
This will never be true.
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] madrob commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
madrob commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r17129
##
File path: solr/core/src/java/org/apache/solr/core/SolrConfig.java
##
@@ -224,6 +224,13 @@ private SolrConfig(SolrResourceLoader loader, String name,
boolean isConfigsetTr
queryResultWindowSize = Math.max(1, getInt("query/queryResultWindowSize",
1));
queryResultMaxDocsCached = getInt("query/queryResultMaxDocsCached",
Integer.MAX_VALUE);
enableLazyFieldLoading = getBool("query/enableLazyFieldLoading", false);
+
+useCircuitBreakers = getBool("query/useCircuitBreakers", false);
+memoryCircuitBreakerThreshold =
getInt("query/memoryCircuitBreakerThreshold", 100);
+
+if (memoryCircuitBreakerThreshold > 100 || memoryCircuitBreakerThreshold <
0) {
Review comment:
We only want to do this validation if circuitBreakers are enabled, right?
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] madrob commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
madrob commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r16519
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/MemoryCircuitBreaker.java
##
@@ -0,0 +1,88 @@
+/*
+ * 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.util.circuitbreaker;
+
+import java.lang.management.ManagementFactory;
+import java.lang.management.MemoryMXBean;
+
+import org.apache.solr.core.SolrCore;
+
+public class MemoryCircuitBreaker extends CircuitBreaker {
+ private static final MemoryMXBean MEMORY_MX_BEAN =
ManagementFactory.getMemoryMXBean();
+
+ // Assumption -- the value of these parameters will be set correctly before
invoking printDebugInfo()
+ private double seenMemory;
+ private double allowedMemory;
+
+ public MemoryCircuitBreaker(SolrCore solrCore) {
+super(solrCore);
+ }
+
+ // TODO: An optimization can be to trip the circuit breaker for a duration
of time
+ // after the circuit breaker condition is matched. This will optimize for
per call
+ // overhead of calculating the condition parameters but can result in false
positives.
+ @Override
+ public boolean isCircuitBreakerGauntletTripped() {
+if (!isCircuitBreakerEnabled()) {
+ return false;
+}
+
+allowedMemory = getCurrentMemoryThreshold();
+
+if (allowedMemory < 0) {
+ // No threshold
+ return false;
+}
+
+seenMemory = calculateLiveMemoryUsage();
+
+return (seenMemory >= allowedMemory);
+ }
+
+ @Override
+ public String printDebugInfo() {
+return "seen memory " + seenMemory + " allowed memory " + allowedMemory;
+ }
+
+ private double getCurrentMemoryThreshold() {
+int thresholdValueInPercentage =
solrCore.getSolrConfig().memoryCircuitBreakerThreshold;
+long currentMaxHeap = MEMORY_MX_BEAN.getHeapMemoryUsage().getMax();
+
+if (currentMaxHeap <= 0) {
+ return Long.MIN_VALUE;
+}
+
+double thresholdInFraction = (double) thresholdValueInPercentage / 100;
+double actualLimit = currentMaxHeap * thresholdInFraction;
+
+if (actualLimit <= 0) {
+ throw new IllegalStateException("Memory limit cannot be less than or
equal to zero");
+}
+
+return actualLimit;
+ }
+
+ /**
+ * Calculate the live memory usage for the system. This method has package
visibility
+ * to allow using for testing
+ * @return Memory usage in bytes
+ */
+ protected long calculateLiveMemoryUsage() {
+return MEMORY_MX_BEAN.getHeapMemoryUsage().getUsed();
Review comment:
This article claims that each call is about 100ns,
https://www.inoneo.com/en/blog/8/java/monitoring-jvm-memory-usage-inside-a-java-application
and suggest using a listener instead. I'm not sure how true this is for more
modern JVMs anyway.
If you look into drop wizard metrics that we're reporting in JMX,
MemoryUsageGuageSet reports memory as the combination of heap and non-heap. I'm
not sure we need to consider non-heap here, but at least a comment highlighting
that would be useful.
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] [Assigned] (SOLR-14588) Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker
[ https://issues.apache.org/jira/browse/SOLR-14588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Atri Sharma reassigned SOLR-14588: -- Assignee: Atri Sharma > Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker > -- > > Key: SOLR-14588 > URL: https://issues.apache.org/jira/browse/SOLR-14588 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Atri Sharma >Assignee: Atri Sharma >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > > This Jira tracks addition of circuit breakers in the search path and > implements JVM based circuit breaker which rejects incoming search requests > if the JVM heap usage exceeds a defined percentage. -- 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] atris commented on pull request #1606: SOLR-14588: Implement Circuit Breakers
atris commented on pull request #1606: URL: https://github.com/apache/lucene-solr/pull/1606#issuecomment-648326325 To provide some context, I ran this against large facets with the memory circuit breaker tripping in the right place. @madrob Thanks for reviewing, I have raised another iteration fixing your comments. Please see and let me know your thoughts and comments. 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] atris commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r444394541
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/MemoryCircuitBreaker.java
##
@@ -0,0 +1,88 @@
+/*
+ * 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.util.circuitbreaker;
+
+import java.lang.management.ManagementFactory;
+import java.lang.management.MemoryMXBean;
+
+import org.apache.solr.core.SolrCore;
+
+public class MemoryCircuitBreaker extends CircuitBreaker {
+ private static final MemoryMXBean MEMORY_MX_BEAN =
ManagementFactory.getMemoryMXBean();
+
+ // Assumption -- the value of these parameters will be set correctly before
invoking printDebugInfo()
+ private double seenMemory;
+ private double allowedMemory;
+
+ public MemoryCircuitBreaker(SolrCore solrCore) {
+super(solrCore);
+ }
+
+ // TODO: An optimization can be to trip the circuit breaker for a duration
of time
+ // after the circuit breaker condition is matched. This will optimize for
per call
+ // overhead of calculating the condition parameters but can result in false
positives.
+ @Override
+ public boolean isCircuitBreakerGauntletTripped() {
+if (!isCircuitBreakerEnabled()) {
+ return false;
+}
+
+allowedMemory = getCurrentMemoryThreshold();
+
+if (allowedMemory < 0) {
+ // No threshold
+ return false;
+}
+
+seenMemory = calculateLiveMemoryUsage();
+
+return (seenMemory >= allowedMemory);
+ }
+
+ @Override
+ public String printDebugInfo() {
+return "seen memory " + seenMemory + " allowed memory " + allowedMemory;
+ }
+
+ private double getCurrentMemoryThreshold() {
+int thresholdValueInPercentage =
solrCore.getSolrConfig().memoryCircuitBreakerThreshold;
+long currentMaxHeap = MEMORY_MX_BEAN.getHeapMemoryUsage().getMax();
+
+if (currentMaxHeap <= 0) {
+ return Long.MIN_VALUE;
+}
+
+double thresholdInFraction = (double) thresholdValueInPercentage / 100;
+double actualLimit = currentMaxHeap * thresholdInFraction;
+
+if (actualLimit <= 0) {
+ throw new IllegalStateException("Memory limit cannot be less than or
equal to zero");
+}
+
+return actualLimit;
+ }
+
+ /**
+ * Calculate the live memory usage for the system. This method has package
visibility
+ * to allow using for testing
+ * @return Memory usage in bytes
+ */
+ protected long calculateLiveMemoryUsage() {
+return MEMORY_MX_BEAN.getHeapMemoryUsage().getUsed();
Review comment:
I did not see any regression -- if we note anything otherwise, we can
probably cache these values with a TTL. I would be surprised if it causes
anything noticeable, though.
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] atris commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r444392412
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/MemoryCircuitBreaker.java
##
@@ -0,0 +1,88 @@
+/*
+ * 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.util.circuitbreaker;
+
+import java.lang.management.ManagementFactory;
+import java.lang.management.MemoryMXBean;
+
+import org.apache.solr.core.SolrCore;
+
+public class MemoryCircuitBreaker extends CircuitBreaker {
+ private static final MemoryMXBean MEMORY_MX_BEAN =
ManagementFactory.getMemoryMXBean();
+
+ // Assumption -- the value of these parameters will be set correctly before
invoking printDebugInfo()
+ private double seenMemory;
+ private double allowedMemory;
+
+ public MemoryCircuitBreaker(SolrCore solrCore) {
+super(solrCore);
+ }
+
+ // TODO: An optimization can be to trip the circuit breaker for a duration
of time
+ // after the circuit breaker condition is matched. This will optimize for
per call
+ // overhead of calculating the condition parameters but can result in false
positives.
+ @Override
+ public boolean isCircuitBreakerGauntletTripped() {
+if (!isCircuitBreakerEnabled()) {
+ return false;
+}
+
+allowedMemory = getCurrentMemoryThreshold();
+
+if (allowedMemory < 0) {
+ // No threshold
+ return false;
+}
+
+seenMemory = calculateLiveMemoryUsage();
+
+return (seenMemory >= allowedMemory);
+ }
+
+ @Override
+ public String printDebugInfo() {
+return "seen memory " + seenMemory + " allowed memory " + allowedMemory;
+ }
+
+ private double getCurrentMemoryThreshold() {
+int thresholdValueInPercentage =
solrCore.getSolrConfig().memoryCircuitBreakerThreshold;
+long currentMaxHeap = MEMORY_MX_BEAN.getHeapMemoryUsage().getMax();
Review comment:
Good point, thanks
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] atris commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r444384399
##
File path: solr/core/src/test/org/apache/solr/util/TestCircuitBreaker.java
##
@@ -0,0 +1,191 @@
+/*
+ * 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.util;
+
+import java.io.IOException;
+import java.util.HashMap;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import org.apache.lucene.util.NamedThreadFactory;
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.params.CommonParams;
+import org.apache.solr.common.util.ExecutorUtil;
+import org.apache.solr.common.util.SolrNamedThreadFactory;
+import org.apache.solr.core.SolrCore;
+import org.apache.solr.search.QueryParsing;
+import org.apache.solr.util.circuitbreaker.CircuitBreaker;
+import org.apache.solr.util.circuitbreaker.CircuitBreakerType;
+import org.apache.solr.util.circuitbreaker.MemoryCircuitBreaker;
+import org.junit.AfterClass;
+import org.junit.BeforeClass;
+
+public class TestCircuitBreaker extends SolrTestCaseJ4 {
+ private final static int NUM_DOCS = 20;
+ private static ExecutorService executor;
+
+ @BeforeClass
+ public static void setUpClass() throws Exception {
+System.setProperty("filterCache.enabled", "false");
+System.setProperty("queryResultCache.enabled", "false");
+System.setProperty("documentCache.enabled", "true");
+
+executor = ExecutorUtil.newMDCAwareCachedThreadPool(
+new SolrNamedThreadFactory("TestCircuitBreaker"));
+initCore("solrconfig-memory-circuitbreaker.xml", "schema.xml");
+for (int i = 0 ; i < NUM_DOCS ; i ++) {
+ assertU(adoc("name", "john smith", "id", "1"));
+ assertU(adoc("name", "johathon smith", "id", "2"));
+ assertU(adoc("name", "john percival smith", "id", "3"));
+ assertU(commit());
+ assertU(optimize());
+
+ //commit inside the loop to get multiple segments to make search as
realistic as possible
+ assertU(commit());
+}
+ }
+
+ @Override
+ public void tearDown() throws Exception {
+executor = null;
+super.tearDown();
+ }
+
+ @AfterClass
+ public static void afterClass() {
+System.clearProperty("filterCache.enabled");
+System.clearProperty("queryResultCache.enabled");
+System.clearProperty("documentCache.enabled");
+ }
+
+ public void testCBAlwaysTrips() throws IOException {
+HashMap args = new HashMap();
+
+args.put(QueryParsing.DEFTYPE, CircuitBreaker.NAME);
+args.put(CommonParams.FL, "id");
+
+CircuitBreaker circuitBreaker = new MockCircuitBreaker(h.getCore());
+
+
h.getCore().getCircuitBreakerManager().registerCircuitBreaker(CircuitBreakerType.MEMORY,
circuitBreaker);
+
+expectThrows(SolrException.class, () -> {
+ h.query(req("name:\"john smith\""));
+});
+ }
+
+ public void testCBFakeMemoryPressure() throws IOException {
+HashMap args = new HashMap();
+
+args.put(QueryParsing.DEFTYPE, CircuitBreaker.NAME);
+args.put(CommonParams.FL, "id");
+
+CircuitBreaker circuitBreaker = new
FakeMemoryPressureCircuitBreaker(h.getCore());
+
+
h.getCore().getCircuitBreakerManager().registerCircuitBreaker(CircuitBreakerType.MEMORY,
circuitBreaker);
+
+expectThrows(SolrException.class, () -> {
+ h.query(req("name:\"john smith\""));
+});
+ }
+
+ public void testBuildingMemoryPressure() throws Exception {
+HashMap args = new HashMap();
+
+args.put(QueryParsing.DEFTYPE, CircuitBreaker.NAME);
+args.put(CommonParams.FL, "id");
+
+AtomicInteger failureCount = new AtomicInteger();
+
+CircuitBreaker circuitBreaker = new
BuildingUpMemoryPressureCircuitBreaker(h.getCore());
+
+
h.getCore().getCircuitBreakerManager().registerCircuitBreaker(CircuitBreakerType.MEMORY,
circuitBreaker);
+
+for (int i = 0; i < 5; i++) {
+ System.out.println("i is " + i);
Review comment:
Stray debugging output, removed, thanks
This is an automated message
[GitHub] [lucene-solr] atris commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r444383850
##
File path: solr/core/src/test/org/apache/solr/util/TestCircuitBreaker.java
##
@@ -0,0 +1,191 @@
+/*
+ * 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.util;
+
+import java.io.IOException;
+import java.util.HashMap;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Executors;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import org.apache.lucene.util.NamedThreadFactory;
+import org.apache.solr.SolrTestCaseJ4;
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.params.CommonParams;
+import org.apache.solr.common.util.ExecutorUtil;
+import org.apache.solr.common.util.SolrNamedThreadFactory;
+import org.apache.solr.core.SolrCore;
+import org.apache.solr.search.QueryParsing;
+import org.apache.solr.util.circuitbreaker.CircuitBreaker;
+import org.apache.solr.util.circuitbreaker.CircuitBreakerType;
+import org.apache.solr.util.circuitbreaker.MemoryCircuitBreaker;
+import org.junit.AfterClass;
+import org.junit.BeforeClass;
+
+public class TestCircuitBreaker extends SolrTestCaseJ4 {
+ private final static int NUM_DOCS = 20;
+ private static ExecutorService executor;
+
+ @BeforeClass
+ public static void setUpClass() throws Exception {
+System.setProperty("filterCache.enabled", "false");
+System.setProperty("queryResultCache.enabled", "false");
+System.setProperty("documentCache.enabled", "true");
+
+executor = ExecutorUtil.newMDCAwareCachedThreadPool(
+new SolrNamedThreadFactory("TestCircuitBreaker"));
+initCore("solrconfig-memory-circuitbreaker.xml", "schema.xml");
+for (int i = 0 ; i < NUM_DOCS ; i ++) {
+ assertU(adoc("name", "john smith", "id", "1"));
+ assertU(adoc("name", "johathon smith", "id", "2"));
+ assertU(adoc("name", "john percival smith", "id", "3"));
+ assertU(commit());
+ assertU(optimize());
+
+ //commit inside the loop to get multiple segments to make search as
realistic as possible
+ assertU(commit());
+}
+ }
+
+ @Override
+ public void tearDown() throws Exception {
+executor = null;
Review comment:
This should be shutdown in the test itself. I have added a check to
check if it is shut down before making the reference null.
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] atris commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r444382798
##
File path: solr/core/src/java/org/apache/solr/core/SolrConfig.java
##
@@ -224,6 +224,9 @@ private SolrConfig(SolrResourceLoader loader, String name,
boolean isConfigsetTr
queryResultWindowSize = Math.max(1, getInt("query/queryResultWindowSize",
1));
queryResultMaxDocsCached = getInt("query/queryResultMaxDocsCached",
Integer.MAX_VALUE);
enableLazyFieldLoading = getBool("query/enableLazyFieldLoading", false);
+
+useCircuitBreakers = getBool("query/useCircuitBreakers", false);
+memoryCircuitBreakerThreshold =
getInt("query/memoryCircuitBreakerThreshold", 100);
Review comment:
Good catch, thanks!
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 9.0
[ https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143124#comment-17143124 ] Ishan Chattopadhyaya commented on SOLR-12823: - Oh, I see. I was confused due to the empty 9x section here https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/solr-upgrade-notes.adoc. [~ctargett], do we need that section? > remove clusterstate.json in Lucene/Solr 9.0 > --- > > Key: SOLR-12823 > URL: https://issues.apache.org/jira/browse/SOLR-12823 > Project: Solr > Issue Type: Task >Reporter: Varun Thacker >Assignee: Ilan Ginzburg >Priority: Major > Fix For: master (9.0) > > Time Spent: 5h > Remaining Estimate: 0h > > clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove > that in 9.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 9.0
[
https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143119#comment-17143119
]
Ilan Ginzburg commented on SOLR-12823:
--
[~ichattopadhyaya] actually the original PR already updated
{{major-changes-in-solr-9.adoc}} so I guess we're ok here, nothing more to do.
> remove clusterstate.json in Lucene/Solr 9.0
> ---
>
> Key: SOLR-12823
> URL: https://issues.apache.org/jira/browse/SOLR-12823
> Project: Solr
> Issue Type: Task
>Reporter: Varun Thacker
>Assignee: Ilan Ginzburg
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 5h
> Remaining Estimate: 0h
>
> clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove
> that in 9.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] [Comment Edited] (SOLR-12823) remove clusterstate.json in Lucene/Solr 9.0
[ https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143089#comment-17143089 ] Ilan Ginzburg edited comment on SOLR-12823 at 6/23/20, 5:06 PM: [~ichattopadhyaya] I'll put out a PR with this. Edit: will be adding major-changes-in-solr-9.adoc and put a comment there, as there's a comment in solr-upgrade-notes.adoc instructing to do so. was (Author: ilan): [~ichattopadhyaya] I'll put out a PR with this. > remove clusterstate.json in Lucene/Solr 9.0 > --- > > Key: SOLR-12823 > URL: https://issues.apache.org/jira/browse/SOLR-12823 > Project: Solr > Issue Type: Task >Reporter: Varun Thacker >Assignee: Ilan Ginzburg >Priority: Major > Fix For: master (9.0) > > Time Spent: 5h > Remaining Estimate: 0h > > clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove > that in 9.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] atris commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
atris commented on a change in pull request #1606: URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r444375970 ## File path: solr/core/src/test-files/solr/collection1/conf/solrconfig-cache-enable-disable.xml ## @@ -70,6 +70,10 @@ 10 +false + +100 Review comment: I dont think so, since it is checked when circuit breakers are enabled. I put this config here for completion. 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] murblanc commented on pull request #1607: SOLR-14546: add a Bug Fixes section for Solr 9.0.0 in CHANGES.txt
murblanc commented on pull request #1607: URL: https://github.com/apache/lucene-solr/pull/1607#issuecomment-648287499 Thanks @ErickErickson. I do understand that and likely will get to it eventually but I prefer to do it that way for now, I likely understand SolrCloud better than I understand Git at this point. And pressing the "Squash and merge" button feels so good TBH... :) 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 #1607: SOLR-14546: add a Bug Fixes section for Solr 9.0.0 in CHANGES.txt
ErickErickson commented on pull request #1607: URL: https://github.com/apache/lucene-solr/pull/1607#issuecomment-648285224 Ilan: There’s no need to burden yourself with much process for something this simple/uncontroversial, ditto with spelling corrections and the like. Up to you of course and I appreciate your care here, OTOH given the kinds of things you’re tackling I don’t want you to be slowed down by administrivia ;) Best, Erick > On Jun 23, 2020, at 12:28 PM, Ilan Ginzburg wrote: > > Description > > Add a "Bug Fixes" section in the Solr 9.0.0 section in CHANGES.txt and move the fix to SOLR-14546 into it. > > Solution > > Text edit. > > You can view, comment on, or merge this pull request online at: > > https://github.com/apache/lucene-solr/pull/1607 > > Commit Summary > >• SOLR-14546: add a Bug Fixes section for Solr 9.0.0 in CHANGES.txt > File Changes > >• M solr/CHANGES.txt (2) > Patch Links: > >• https://github.com/apache/lucene-solr/pull/1607.patch >• https://github.com/apache/lucene-solr/pull/1607.diff > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub, or unsubscribe. > 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-14546) OverseerTaskProcessor can process messages out of order
[
https://issues.apache.org/jira/browse/SOLR-14546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilan Ginzburg resolved SOLR-14546.
--
Resolution: Fixed
> OverseerTaskProcessor can process messages out of order
> ---
>
> Key: SOLR-14546
> URL: https://issues.apache.org/jira/browse/SOLR-14546
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Ilan Ginzburg
>Assignee: Ilan Ginzburg
>Priority: Major
> Labels: collection-api, correctness, overseer
> Time Spent: 3h
> Remaining Estimate: 0h
>
> *Summary:*
> Collection API and ConfigSet API messages can be processed out of order by
> the {{OverseerTaskProcessor}}/{{OverseerCollectionConfigSetProcessor}}
> because of the way locking is handled.
>
> *Some context:*
> The Overseer task processor dequeues messages from the Collection and
> ConfigSet Zookeeper queue at {{/overseer/collection-queue-work}} and hands
> processing to an executor pool with 100 max parallel tasks
> ({{ClusterStateUpdater}} on the other hand uses a single thread consuming and
> processing the {{/overseer/queue}} and does not suffer from the problem
> described here).
> Locking prevents tasks modifying the same or related data from running
> concurrently. For the Collection API, locking can be done at {{CLUSTER}},
> {{COLLECTION}}, {{SHARD}} or {{REPLICA}} level and each command has its
> locking level defined in {{CollectionParams.CollectionAction}}.
> Multiple tasks for the same or competing locking levels do not execute
> concurrently. Commands locking at {{COLLECTION}} level for the same
> collection (for example {{CREATE}} creating a collection, {{CREATEALIAS}}
> creating an alias for the collection and {{CREATESHARD}} creating a new shard
> for the collection) will be executed sequentially, and it is expected that
> they are executed in submission order. Commands locking at different levels
> are also serialized when needed (for example changes to a shard of a
> collection and changes to the collection itself).
>
> *The issue:*
> The way {{OverseerTaskProcessor.run()}} deals with messages that cannot be
> executed due to competing messages already running (i.e. lock unavailable) is
> not correct. The method basically iterates over the set of messages to
> execute, skips those that can’t be executed due to locking and executes those
> that can be (assuming enough remaining available executors).
> The issue of out of order execution occurs when at least 3 messages compete
> for a lock. The following scenario shows out of order execution (messages
> numbered in enqueue order):
> * Message 1 gets the lock and runs,
> * Message 2 can’t be executed because the lock is taken,
> * Message 1 finishes execution and releases the lock,
> * Message 3 can be executed, gets the lock and runs,
> * Message 2 eventually runs when Message 3 finishes and releases the lock.
> We therefore have execution order 1 - 3 - 2 when the expected execution order
> is 1 - 2 - 3. Order 1 - 3 - 2 might not make sense or result in a different
> final state from 1 - 2 - 3.
> (there’s a variant of this scenario in which after Message 2 can't be
> executed the number of max parallel tasks is reached, then remaining tasks in
> {{heads}} including Message 3 are put into the {{blockedTasks}} map. These
> tasks are the first ones considered for processing on the next iteration of
> the main {{while}} loop. The reordering is similar).
>
> Note that from the client perspective, there does not need to be 3
> outstanding tasks, 2 are sufficient. The third task required for observing
> reordering could be enqueued after the first one completed.
>
> *Impact of the issue:*
> This problem makes {{MultiThreadedOCPTest.testFillWorkQueue()}} fail because
> the test requires task execution in submission order (SOLR-14524).
>
> The messages required for reordering to happen are not necessarily messages
> at the same locking level: a message locking at {{SHARD}} or {{REPLICA}}
> level prevents execution of a {{COLLECTION}} level message for the same
> collection. Examples can be built of sequences of messages that lead to
> incorrect results or failures. For example {{ADDREPLICA}} followed by
> {{CREATEALIAS}} followed by {{DELETEALIAS}}, could see alias creation and
> deletion reordered, making no sense.
> I wasn’t able to come up with a realistic production example that would be
> impacted by this issue (doesn't mean one doesn't exist!).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail:
[jira] [Commented] (SOLR-14546) OverseerTaskProcessor can process messages out of order
[
https://issues.apache.org/jira/browse/SOLR-14546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143091#comment-17143091
]
ASF subversion and git services commented on SOLR-14546:
Commit 3c6e09268cc806daec05f2cdbdeb380ab0721309 in lucene-solr's branch
refs/heads/master from Ilan Ginzburg
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3c6e092 ]
SOLR-14546: add a Bug Fixes section for Solr 9.0.0 in CHANGES.txt (#1607)
> OverseerTaskProcessor can process messages out of order
> ---
>
> Key: SOLR-14546
> URL: https://issues.apache.org/jira/browse/SOLR-14546
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Ilan Ginzburg
>Assignee: Ilan Ginzburg
>Priority: Major
> Labels: collection-api, correctness, overseer
> Time Spent: 3h
> Remaining Estimate: 0h
>
> *Summary:*
> Collection API and ConfigSet API messages can be processed out of order by
> the {{OverseerTaskProcessor}}/{{OverseerCollectionConfigSetProcessor}}
> because of the way locking is handled.
>
> *Some context:*
> The Overseer task processor dequeues messages from the Collection and
> ConfigSet Zookeeper queue at {{/overseer/collection-queue-work}} and hands
> processing to an executor pool with 100 max parallel tasks
> ({{ClusterStateUpdater}} on the other hand uses a single thread consuming and
> processing the {{/overseer/queue}} and does not suffer from the problem
> described here).
> Locking prevents tasks modifying the same or related data from running
> concurrently. For the Collection API, locking can be done at {{CLUSTER}},
> {{COLLECTION}}, {{SHARD}} or {{REPLICA}} level and each command has its
> locking level defined in {{CollectionParams.CollectionAction}}.
> Multiple tasks for the same or competing locking levels do not execute
> concurrently. Commands locking at {{COLLECTION}} level for the same
> collection (for example {{CREATE}} creating a collection, {{CREATEALIAS}}
> creating an alias for the collection and {{CREATESHARD}} creating a new shard
> for the collection) will be executed sequentially, and it is expected that
> they are executed in submission order. Commands locking at different levels
> are also serialized when needed (for example changes to a shard of a
> collection and changes to the collection itself).
>
> *The issue:*
> The way {{OverseerTaskProcessor.run()}} deals with messages that cannot be
> executed due to competing messages already running (i.e. lock unavailable) is
> not correct. The method basically iterates over the set of messages to
> execute, skips those that can’t be executed due to locking and executes those
> that can be (assuming enough remaining available executors).
> The issue of out of order execution occurs when at least 3 messages compete
> for a lock. The following scenario shows out of order execution (messages
> numbered in enqueue order):
> * Message 1 gets the lock and runs,
> * Message 2 can’t be executed because the lock is taken,
> * Message 1 finishes execution and releases the lock,
> * Message 3 can be executed, gets the lock and runs,
> * Message 2 eventually runs when Message 3 finishes and releases the lock.
> We therefore have execution order 1 - 3 - 2 when the expected execution order
> is 1 - 2 - 3. Order 1 - 3 - 2 might not make sense or result in a different
> final state from 1 - 2 - 3.
> (there’s a variant of this scenario in which after Message 2 can't be
> executed the number of max parallel tasks is reached, then remaining tasks in
> {{heads}} including Message 3 are put into the {{blockedTasks}} map. These
> tasks are the first ones considered for processing on the next iteration of
> the main {{while}} loop. The reordering is similar).
>
> Note that from the client perspective, there does not need to be 3
> outstanding tasks, 2 are sufficient. The third task required for observing
> reordering could be enqueued after the first one completed.
>
> *Impact of the issue:*
> This problem makes {{MultiThreadedOCPTest.testFillWorkQueue()}} fail because
> the test requires task execution in submission order (SOLR-14524).
>
> The messages required for reordering to happen are not necessarily messages
> at the same locking level: a message locking at {{SHARD}} or {{REPLICA}}
> level prevents execution of a {{COLLECTION}} level message for the same
> collection. Examples can be built of sequences of messages that lead to
> incorrect results or failures. For example {{ADDREPLICA}} followed by
> {{CREATEALIAS}} followed by {{DELETEALIAS}}, could see alias creation and
> deletion reordered, making no sense.
> I wasn’t able
[jira] [Commented] (SOLR-14582) Expose IWC.setMaxCommitMergeWaitSeconds as an expert feature in Solr's index config
[
https://issues.apache.org/jira/browse/SOLR-14582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143093#comment-17143093
]
Mike Drob commented on SOLR-14582:
--
Should we have a warning if somebody tries to use this with the default
MergePolicy to indicate that there will be no effect?
> Expose IWC.setMaxCommitMergeWaitSeconds as an expert feature in Solr's index
> config
> ---
>
> Key: SOLR-14582
> URL: https://issues.apache.org/jira/browse/SOLR-14582
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Tomas Eduardo Fernandez Lobbe
>Priority: Trivial
>
> LUCENE-8962 added the ability to merge segments synchronously on commit. This
> isn't done by default and the default {{MergePolicy}} won't do it, but custom
> merge policies can take advantage of this. Solr allows plugging in custom
> merge policies, so if someone wants to make use of this feature they could,
> however, they need to set {{IndexWriterConfig.maxCommitMergeWaitSeconds}} to
> something greater than 0.
> Since this is an expert feature, I plan to document it only in javadoc and
> not the ref guide.
--
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 merged pull request #1607: SOLR-14546: add a Bug Fixes section for Solr 9.0.0 in CHANGES.txt
murblanc merged pull request #1607: URL: https://github.com/apache/lucene-solr/pull/1607 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 9.0
[ https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143089#comment-17143089 ] Ilan Ginzburg commented on SOLR-12823: -- [~ichattopadhyaya] I'll put out a PR with this. > remove clusterstate.json in Lucene/Solr 9.0 > --- > > Key: SOLR-12823 > URL: https://issues.apache.org/jira/browse/SOLR-12823 > Project: Solr > Issue Type: Task >Reporter: Varun Thacker >Assignee: Ilan Ginzburg >Priority: Major > Fix For: master (9.0) > > Time Spent: 5h > Remaining Estimate: 0h > > clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove > that in 9.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-14546) OverseerTaskProcessor can process messages out of order
[
https://issues.apache.org/jira/browse/SOLR-14546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143085#comment-17143085
]
Ilan Ginzburg commented on SOLR-14546:
--
[https://github.com/apache/lucene-solr/pull/1607]
> OverseerTaskProcessor can process messages out of order
> ---
>
> Key: SOLR-14546
> URL: https://issues.apache.org/jira/browse/SOLR-14546
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Ilan Ginzburg
>Assignee: Ilan Ginzburg
>Priority: Major
> Labels: collection-api, correctness, overseer
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> *Summary:*
> Collection API and ConfigSet API messages can be processed out of order by
> the {{OverseerTaskProcessor}}/{{OverseerCollectionConfigSetProcessor}}
> because of the way locking is handled.
>
> *Some context:*
> The Overseer task processor dequeues messages from the Collection and
> ConfigSet Zookeeper queue at {{/overseer/collection-queue-work}} and hands
> processing to an executor pool with 100 max parallel tasks
> ({{ClusterStateUpdater}} on the other hand uses a single thread consuming and
> processing the {{/overseer/queue}} and does not suffer from the problem
> described here).
> Locking prevents tasks modifying the same or related data from running
> concurrently. For the Collection API, locking can be done at {{CLUSTER}},
> {{COLLECTION}}, {{SHARD}} or {{REPLICA}} level and each command has its
> locking level defined in {{CollectionParams.CollectionAction}}.
> Multiple tasks for the same or competing locking levels do not execute
> concurrently. Commands locking at {{COLLECTION}} level for the same
> collection (for example {{CREATE}} creating a collection, {{CREATEALIAS}}
> creating an alias for the collection and {{CREATESHARD}} creating a new shard
> for the collection) will be executed sequentially, and it is expected that
> they are executed in submission order. Commands locking at different levels
> are also serialized when needed (for example changes to a shard of a
> collection and changes to the collection itself).
>
> *The issue:*
> The way {{OverseerTaskProcessor.run()}} deals with messages that cannot be
> executed due to competing messages already running (i.e. lock unavailable) is
> not correct. The method basically iterates over the set of messages to
> execute, skips those that can’t be executed due to locking and executes those
> that can be (assuming enough remaining available executors).
> The issue of out of order execution occurs when at least 3 messages compete
> for a lock. The following scenario shows out of order execution (messages
> numbered in enqueue order):
> * Message 1 gets the lock and runs,
> * Message 2 can’t be executed because the lock is taken,
> * Message 1 finishes execution and releases the lock,
> * Message 3 can be executed, gets the lock and runs,
> * Message 2 eventually runs when Message 3 finishes and releases the lock.
> We therefore have execution order 1 - 3 - 2 when the expected execution order
> is 1 - 2 - 3. Order 1 - 3 - 2 might not make sense or result in a different
> final state from 1 - 2 - 3.
> (there’s a variant of this scenario in which after Message 2 can't be
> executed the number of max parallel tasks is reached, then remaining tasks in
> {{heads}} including Message 3 are put into the {{blockedTasks}} map. These
> tasks are the first ones considered for processing on the next iteration of
> the main {{while}} loop. The reordering is similar).
>
> Note that from the client perspective, there does not need to be 3
> outstanding tasks, 2 are sufficient. The third task required for observing
> reordering could be enqueued after the first one completed.
>
> *Impact of the issue:*
> This problem makes {{MultiThreadedOCPTest.testFillWorkQueue()}} fail because
> the test requires task execution in submission order (SOLR-14524).
>
> The messages required for reordering to happen are not necessarily messages
> at the same locking level: a message locking at {{SHARD}} or {{REPLICA}}
> level prevents execution of a {{COLLECTION}} level message for the same
> collection. Examples can be built of sequences of messages that lead to
> incorrect results or failures. For example {{ADDREPLICA}} followed by
> {{CREATEALIAS}} followed by {{DELETEALIAS}}, could see alias creation and
> deletion reordered, making no sense.
> I wasn’t able to come up with a realistic production example that would be
> impacted by this issue (doesn't mean one doesn't exist!).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [lucene-solr] murblanc opened a new pull request #1607: SOLR-14546: add a Bug Fixes section for Solr 9.0.0 in CHANGES.txt
murblanc opened a new pull request #1607: URL: https://github.com/apache/lucene-solr/pull/1607 # Description Add a "Bug Fixes" section in the Solr 9.0.0 section in CHANGES.txt and move the fix to SOLR-14546 into it. # Solution Text edit. 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] madrob commented on pull request #1606: SOLR-14588: Implement Circuit Breakers
madrob commented on pull request #1606: URL: https://github.com/apache/lucene-solr/pull/1606#issuecomment-648271244 This has been something that I've wanted for a long time, so I'm really excited to see somebody picking up the work! Thank you @atris ! 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-14560) Learning To Rank Interleaving
[ https://issues.apache.org/jira/browse/SOLR-14560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143078#comment-17143078 ] Christine Poerschke commented on SOLR-14560: Haven't yet had a chance to learn about interleaving myself but just wanted to tag [~yuyano] and [~malcorn_redhat] as additional folks who might also be interested in this (connections e.g. via SOLR-11250 and loosely SOLR-11513 and SOLR-11597 tickets). > Learning To Rank Interleaving > - > > Key: SOLR-14560 > URL: https://issues.apache.org/jira/browse/SOLR-14560 > Project: Solr > Issue Type: New Feature > Security Level: Public(Default Security Level. Issues are Public) > Components: contrib - LTR >Affects Versions: 8.5.2 >Reporter: Alessandro Benedetti >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Interleaving is an approach to Online Search Quality evaluation that can be > very useful for Learning To Rank models: > [https://sease.io/2020/05/online-testing-for-learning-to-rank-interleaving.html|https://sease.io/2020/05/online-testing-for-learning-to-rank-interleaving.html] > Scope of this issue is to introduce the ability to the LTR query parser of > accepting multiple models (2 to start with). > If one model is passed, normal reranking happens. > If two models are passed, reranking happens for both models and the final > reranked list is the interleaved sequence of results coming from the two > models lists. > As a first step it is going to be implemented through: > TeamDraft Interleaving with two models in input. > In the future, we can expand the functionality adding the interleaving > algorithm as a parameter. -- 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 commented on a change in pull request #1606: SOLR-14588: Implement Circuit Breakers
madrob commented on a change in pull request #1606:
URL: https://github.com/apache/lucene-solr/pull/1606#discussion_r444334278
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/CircuitBreakerManager.java
##
@@ -0,0 +1,86 @@
+/*
+ * 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.util.circuitbreaker;
+
+import java.util.HashMap;
+import java.util.Map;
+
+/**
+ * Manages all registered circuit breaker instances. Responsible for a
holistic view
+ * of whether a circuit breaker has tripped or not.
+ *
+ * There are two typical ways of using this class's instance:
+ * 1. Check if any circuit breaker has triggered -- and know which circuit
breaker has triggered.
+ * 2. Get an instance of a specific circuit breaker and perform checks.
+ *
+ * It is a good practise to register new circuit breakers here if you want
them checked for every
+ * request.
+ */
+public class CircuitBreakerManager {
+
+ private final Map circuitBreakerMap =
new HashMap<>();
+
+ // Allows replacing of existing circuit breaker
+ public void registerCircuitBreaker(CircuitBreakerType circuitBreakerType,
CircuitBreaker circuitBreaker) {
+assert circuitBreakerType != null && circuitBreaker != null;
+
+circuitBreakerMap.put(circuitBreakerType, circuitBreaker);
+ }
+
+ public CircuitBreaker getCircuitBreaker(CircuitBreakerType
circuitBreakerType) {
+assert circuitBreakerType != null;
+
+return circuitBreakerMap.get(circuitBreakerType);
+ }
+
+ /**
+ * Check if any circuit breaker has triggered.
+ * @return CircuitBreakers which have triggered, null otherwise
+ */
+ public Map checkAllCircuitBreakers() {
+Map triggeredCircuitBreakers = new
HashMap<>();
+
+for (CircuitBreakerType circuitBreakerType : circuitBreakerMap.keySet()) {
Review comment:
prefer `entrySet`
##
File path:
solr/core/src/java/org/apache/solr/util/circuitbreaker/MemoryCircuitBreaker.java
##
@@ -0,0 +1,88 @@
+/*
+ * 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.util.circuitbreaker;
+
+import java.lang.management.ManagementFactory;
+import java.lang.management.MemoryMXBean;
+
+import org.apache.solr.core.SolrCore;
+
+public class MemoryCircuitBreaker extends CircuitBreaker {
+ private static final MemoryMXBean MEMORY_MX_BEAN =
ManagementFactory.getMemoryMXBean();
+
+ // Assumption -- the value of these parameters will be set correctly before
invoking printDebugInfo()
+ private double seenMemory;
+ private double allowedMemory;
+
+ public MemoryCircuitBreaker(SolrCore solrCore) {
+super(solrCore);
+ }
+
+ // TODO: An optimization can be to trip the circuit breaker for a duration
of time
+ // after the circuit breaker condition is matched. This will optimize for
per call
+ // overhead of calculating the condition parameters but can result in false
positives.
+ @Override
+ public boolean isCircuitBreakerGauntletTripped() {
+if (!isCircuitBreakerEnabled()) {
+ return false;
+}
+
+allowedMemory = getCurrentMemoryThreshold();
+
+if (allowedMemory < 0) {
+ // No threshold
+ return false;
+}
+
+seenMemory = calculateLiveMemoryUsage();
+
+return (seenMemory >= allowedMemory);
+ }
+
+ @Override
+ public String printDebugInfo() {
+return "seen memory " + seenMemory + " allowed memory " + allowedMemory;
Review comment:
this would be better as seenMemory=X
[jira] [Commented] (SOLR-14546) OverseerTaskProcessor can process messages out of order
[
https://issues.apache.org/jira/browse/SOLR-14546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143073#comment-17143073
]
Ilan Ginzburg commented on SOLR-14546:
--
Sure [~ichattopadhyaya], thank for spotting this that totally escaped me.
I'll create the Bug Fixes section for 9.0.0 and move it there.
> OverseerTaskProcessor can process messages out of order
> ---
>
> Key: SOLR-14546
> URL: https://issues.apache.org/jira/browse/SOLR-14546
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Ilan Ginzburg
>Assignee: Ilan Ginzburg
>Priority: Major
> Labels: collection-api, correctness, overseer
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Summary:*
> Collection API and ConfigSet API messages can be processed out of order by
> the {{OverseerTaskProcessor}}/{{OverseerCollectionConfigSetProcessor}}
> because of the way locking is handled.
>
> *Some context:*
> The Overseer task processor dequeues messages from the Collection and
> ConfigSet Zookeeper queue at {{/overseer/collection-queue-work}} and hands
> processing to an executor pool with 100 max parallel tasks
> ({{ClusterStateUpdater}} on the other hand uses a single thread consuming and
> processing the {{/overseer/queue}} and does not suffer from the problem
> described here).
> Locking prevents tasks modifying the same or related data from running
> concurrently. For the Collection API, locking can be done at {{CLUSTER}},
> {{COLLECTION}}, {{SHARD}} or {{REPLICA}} level and each command has its
> locking level defined in {{CollectionParams.CollectionAction}}.
> Multiple tasks for the same or competing locking levels do not execute
> concurrently. Commands locking at {{COLLECTION}} level for the same
> collection (for example {{CREATE}} creating a collection, {{CREATEALIAS}}
> creating an alias for the collection and {{CREATESHARD}} creating a new shard
> for the collection) will be executed sequentially, and it is expected that
> they are executed in submission order. Commands locking at different levels
> are also serialized when needed (for example changes to a shard of a
> collection and changes to the collection itself).
>
> *The issue:*
> The way {{OverseerTaskProcessor.run()}} deals with messages that cannot be
> executed due to competing messages already running (i.e. lock unavailable) is
> not correct. The method basically iterates over the set of messages to
> execute, skips those that can’t be executed due to locking and executes those
> that can be (assuming enough remaining available executors).
> The issue of out of order execution occurs when at least 3 messages compete
> for a lock. The following scenario shows out of order execution (messages
> numbered in enqueue order):
> * Message 1 gets the lock and runs,
> * Message 2 can’t be executed because the lock is taken,
> * Message 1 finishes execution and releases the lock,
> * Message 3 can be executed, gets the lock and runs,
> * Message 2 eventually runs when Message 3 finishes and releases the lock.
> We therefore have execution order 1 - 3 - 2 when the expected execution order
> is 1 - 2 - 3. Order 1 - 3 - 2 might not make sense or result in a different
> final state from 1 - 2 - 3.
> (there’s a variant of this scenario in which after Message 2 can't be
> executed the number of max parallel tasks is reached, then remaining tasks in
> {{heads}} including Message 3 are put into the {{blockedTasks}} map. These
> tasks are the first ones considered for processing on the next iteration of
> the main {{while}} loop. The reordering is similar).
>
> Note that from the client perspective, there does not need to be 3
> outstanding tasks, 2 are sufficient. The third task required for observing
> reordering could be enqueued after the first one completed.
>
> *Impact of the issue:*
> This problem makes {{MultiThreadedOCPTest.testFillWorkQueue()}} fail because
> the test requires task execution in submission order (SOLR-14524).
>
> The messages required for reordering to happen are not necessarily messages
> at the same locking level: a message locking at {{SHARD}} or {{REPLICA}}
> level prevents execution of a {{COLLECTION}} level message for the same
> collection. Examples can be built of sequences of messages that lead to
> incorrect results or failures. For example {{ADDREPLICA}} followed by
> {{CREATEALIAS}} followed by {{DELETEALIAS}}, could see alias creation and
> deletion reordered, making no sense.
> I wasn’t able to come up with a realistic production example that would be
> impacted by this issue (doesn't mean one doesn't exist!).
--
This message was sent
[jira] [Commented] (SOLR-14376) Optimize SolrIndexSearcher.getDocSet and getProcessedFilter for empty fq
[
https://issues.apache.org/jira/browse/SOLR-14376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143071#comment-17143071
]
Christine Poerschke commented on SOLR-14376:
quick question: just spotted a
{code:java}
// TODO optimize getDocSet to make this check unnecessary SOLR-14376
{code}
comment at
[https://github.com/apache/lucene-solr/blob/5bfbdc5325aa331549e9700734042c9b582fc3fc/solr/contrib/ltr/src/java/org/apache/solr/ltr/feature/SolrFeature.java#L176]and
not sure if that was inadvertently left in (SOLR-14376 is resolved here) or if
it should be kept but updated somehow perhaps? thanks!
> Optimize SolrIndexSearcher.getDocSet and getProcessedFilter for empty fq
>
>
> Key: SOLR-14376
> URL: https://issues.apache.org/jira/browse/SOLR-14376
> Project: Solr
> Issue Type: Improvement
> Components: search
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Major
> Fix For: 8.6
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If either SolrIndexSearcher.getDocSet or getProcessedFilter are called with
> an null/empty query list, we should be able to short-circuit this with a
> getLiveDocSet response. Today getDocSet builds up a new DocSet, bit by bit
> :-/
--
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] (LUCENE-9411) Fail complation on warnings, 9x gradle-only
[ https://issues.apache.org/jira/browse/LUCENE-9411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated LUCENE-9411: --- Summary: Fail complation on warnings, 9x gradle-only (was: Fail complation on warnings) > Fail complation on warnings, 9x gradle-only > --- > > Key: LUCENE-9411 > URL: https://issues.apache.org/jira/browse/LUCENE-9411 > Project: Lucene - Core > Issue Type: Improvement > Components: general/build >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Labels: build > Attachments: LUCENE-9411.patch, LUCENE-9411.patch, LUCENE-9411.patch, > LUCENE-9411.patch, annotations-warnings.patch > > > Moving this over here from SOLR-11973 since it's part of the build system and > affects Lucene as well as Solr. You might want to see the discussion there. > We have a clean compile for both Solr and Lucene, no rawtypes, unchecked, > try, etc. warnings. There are some peculiar warnings (things like > SuppressFBWarnings, i.e. FindBugs) that I'm not sure about at all, but let's > assume those are not a problem. Now I'd like to start failing the compilation > if people write new code that generates warnings. > From what I can tell, just adding the flag is easy in both the Gradle and Ant > builds. I still have to prove out that adding -Werrors does what I expect, > i.e. succeeds now and fails when I introduce warnings. > But let's assume that works. Are there objections to this idea generally? I > hope to have some data by next Monday. > FWIW, the Lucene code base had far fewer issues than Solr, but > common-build.xml is in Lucene. -- 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-12698) SolrFeature: no-fq optimisation
[ https://issues.apache.org/jira/browse/SOLR-12698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143069#comment-17143069 ] Christine Poerschke commented on SOLR-12698: Returning to this. Looks like [~dsmiley]'s SOLR-14364 and SOLR-14376 changes did an equivalent alternative no-fq optimisation in the meantime. > SolrFeature: no-fq optimisation > --- > > Key: SOLR-12698 > URL: https://issues.apache.org/jira/browse/SOLR-12698 > Project: Solr > Issue Type: Sub-task > Components: contrib - LTR >Reporter: Stanislav Livotov >Priority: Major > Attachments: SOLR-12698.patch > > > [~slivotov] wrote in SOLR-12688: > bq. ... SolrFeature was not optimally implemented for the case when no fq > parameter was passed. I'm not absolutely sure what was the intention to > introduce both q(which is supposed to be a function query) and fq parameter > for the same SolrFeature at all(Is there a case when they will be used > together ? ), so I decided not to change behavior but just optimize described > case ... > (Please see SOLR-12688 description for overall context and analysis results.) -- 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-14588) Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker
[ https://issues.apache.org/jira/browse/SOLR-14588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143064#comment-17143064 ] Mike Drob commented on SOLR-14588: -- See also SOLR-6930 > Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker > -- > > Key: SOLR-14588 > URL: https://issues.apache.org/jira/browse/SOLR-14588 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Atri Sharma >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This Jira tracks addition of circuit breakers in the search path and > implements JVM based circuit breaker which rejects incoming search requests > if the JVM heap usage exceeds a defined percentage. -- 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 commented on a change in pull request #1592: SOLR-14579 First pass at dismantling Utils
madrob commented on a change in pull request #1592:
URL: https://github.com/apache/lucene-solr/pull/1592#discussion_r444325409
##
File path:
solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimClusterStateProvider.java
##
@@ -191,7 +190,7 @@ public DocCollection getColl() throws InterruptedException,
IOException {
}
Map props;
synchronized (ri) {
- props = new HashMap<>(ri.getVariables());
+ props = new HashMap(ri.getVariables());
Review comment:
I don't think we need this?
##
File path:
solr/core/src/java/org/apache/solr/cloud/autoscaling/AutoScalingHandler.java
##
@@ -542,7 +542,7 @@ private AutoScalingConfig handleSetTrigger(SolrQueryRequest
req, SolrQueryRespon
String eventTypeStr = op.getStr(EVENT);
if (op.hasError()) return currentConfig;
-TriggerEventType eventType =
TriggerEventType.valueOf(eventTypeStr.trim().toUpperCase(Locale.ROOT));
+TriggerEventType.valueOf(eventTypeStr.trim().toUpperCase(Locale.ROOT));
Review comment:
I think you can remove the whole line.
##
File path:
solr/core/src/java/org/apache/solr/cloud/autoscaling/sim/SimClusterStateProvider.java
##
@@ -2293,15 +2274,14 @@ public void simSetShardValue(String collection, String
shard, String key, Object
}
}
- @SuppressWarnings({"unchecked"})
public void simSetReplicaValues(String node, Map>> source, boolean overwrite) {
List infos = nodeReplicaMap.get(node);
if (infos == null) {
throw new RuntimeException("Node not present: " + node);
}
// core_node_name is not unique across collections
-Map> infoMap = new HashMap<>();
-infos.forEach(ri -> infoMap.computeIfAbsent(ri.getCollection(),
Utils.NEW_HASHMAP_FUN).put(ri.getName(), ri));
+Map> infoMap = new HashMap>();
Review comment:
`<>` is fine 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] atris opened a new pull request #1606: SOLR-14588: Implement Circuit Breakers
atris opened a new pull request #1606: URL: https://github.com/apache/lucene-solr/pull/1606 This commit consists of two parts: initial circuit breakers infrastructure and real JVM memory based circuit breaker which monitors incoming search requests and rejects them with SERVICE_TOO_BUSY error if the defined threshold is breached, thus giving headroom to existing indexing and search requests to complete. 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 9.0
[ https://issues.apache.org/jira/browse/SOLR-12823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143061#comment-17143061 ] Ishan Chattopadhyaya commented on SOLR-12823: - I think we should add an upgrade note for this change here: https://github.com/apache/lucene-solr/blob/master/solr/solr-ref-guide/src/solr-upgrade-notes.adoc. > remove clusterstate.json in Lucene/Solr 9.0 > --- > > Key: SOLR-12823 > URL: https://issues.apache.org/jira/browse/SOLR-12823 > Project: Solr > Issue Type: Task >Reporter: Varun Thacker >Assignee: Ilan Ginzburg >Priority: Major > Fix For: master (9.0) > > Time Spent: 5h > Remaining Estimate: 0h > > clusterstate.json is an artifact of a pre 5.0 Solr release. We should remove > that in 9.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] madrob commented on a change in pull request #1598: SOLR-14409: Existing violations allow bypassing policy rules when add…
madrob commented on a change in pull request #1598:
URL: https://github.com/apache/lucene-solr/pull/1598#discussion_r444323329
##
File path:
solr/solrj/src/test/org/apache/solr/client/solrj/cloud/autoscaling/TestPolicy2.java
##
@@ -516,6 +517,16 @@ public void testInfiniteLoop() {
System.out.println(suggestions);
}
+ public void testAddTooManyPerPolicy() {
+Map m = (Map)
loadFromResource("testAddTooManyPerPolicy.json");
+SolrCloudManager cloudManagerFromDiagnostics =
createCloudManagerFromDiagnostics(m);
+AutoScalingConfig autoScalingConfig = new AutoScalingConfig((Map) getObjectByPath(m, false, "diagnostics/config"));
+SolrException exp = expectThrows(SolrException.class, () ->
PolicyHelper.getReplicaLocations("TooManyPerPolicy", autoScalingConfig,
cloudManagerFromDiagnostics,
+EMPTY_MAP, Collections.singletonList("shard1"), 1, 0, 0, null));
+assertTrue(exp.getMessage().contains("No node can satisfy the rules"));
Review comment:
`assertThat(exp.getMessage(), contains("..."))`
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-14546) OverseerTaskProcessor can process messages out of order
[
https://issues.apache.org/jira/browse/SOLR-14546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143059#comment-17143059
]
Ishan Chattopadhyaya commented on SOLR-14546:
-
[~ilan], Shouldn't we place this changelog in "Bugfix" section instead of
"Other Changes"?
> OverseerTaskProcessor can process messages out of order
> ---
>
> Key: SOLR-14546
> URL: https://issues.apache.org/jira/browse/SOLR-14546
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: master (9.0)
>Reporter: Ilan Ginzburg
>Assignee: Ilan Ginzburg
>Priority: Major
> Labels: collection-api, correctness, overseer
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Summary:*
> Collection API and ConfigSet API messages can be processed out of order by
> the {{OverseerTaskProcessor}}/{{OverseerCollectionConfigSetProcessor}}
> because of the way locking is handled.
>
> *Some context:*
> The Overseer task processor dequeues messages from the Collection and
> ConfigSet Zookeeper queue at {{/overseer/collection-queue-work}} and hands
> processing to an executor pool with 100 max parallel tasks
> ({{ClusterStateUpdater}} on the other hand uses a single thread consuming and
> processing the {{/overseer/queue}} and does not suffer from the problem
> described here).
> Locking prevents tasks modifying the same or related data from running
> concurrently. For the Collection API, locking can be done at {{CLUSTER}},
> {{COLLECTION}}, {{SHARD}} or {{REPLICA}} level and each command has its
> locking level defined in {{CollectionParams.CollectionAction}}.
> Multiple tasks for the same or competing locking levels do not execute
> concurrently. Commands locking at {{COLLECTION}} level for the same
> collection (for example {{CREATE}} creating a collection, {{CREATEALIAS}}
> creating an alias for the collection and {{CREATESHARD}} creating a new shard
> for the collection) will be executed sequentially, and it is expected that
> they are executed in submission order. Commands locking at different levels
> are also serialized when needed (for example changes to a shard of a
> collection and changes to the collection itself).
>
> *The issue:*
> The way {{OverseerTaskProcessor.run()}} deals with messages that cannot be
> executed due to competing messages already running (i.e. lock unavailable) is
> not correct. The method basically iterates over the set of messages to
> execute, skips those that can’t be executed due to locking and executes those
> that can be (assuming enough remaining available executors).
> The issue of out of order execution occurs when at least 3 messages compete
> for a lock. The following scenario shows out of order execution (messages
> numbered in enqueue order):
> * Message 1 gets the lock and runs,
> * Message 2 can’t be executed because the lock is taken,
> * Message 1 finishes execution and releases the lock,
> * Message 3 can be executed, gets the lock and runs,
> * Message 2 eventually runs when Message 3 finishes and releases the lock.
> We therefore have execution order 1 - 3 - 2 when the expected execution order
> is 1 - 2 - 3. Order 1 - 3 - 2 might not make sense or result in a different
> final state from 1 - 2 - 3.
> (there’s a variant of this scenario in which after Message 2 can't be
> executed the number of max parallel tasks is reached, then remaining tasks in
> {{heads}} including Message 3 are put into the {{blockedTasks}} map. These
> tasks are the first ones considered for processing on the next iteration of
> the main {{while}} loop. The reordering is similar).
>
> Note that from the client perspective, there does not need to be 3
> outstanding tasks, 2 are sufficient. The third task required for observing
> reordering could be enqueued after the first one completed.
>
> *Impact of the issue:*
> This problem makes {{MultiThreadedOCPTest.testFillWorkQueue()}} fail because
> the test requires task execution in submission order (SOLR-14524).
>
> The messages required for reordering to happen are not necessarily messages
> at the same locking level: a message locking at {{SHARD}} or {{REPLICA}}
> level prevents execution of a {{COLLECTION}} level message for the same
> collection. Examples can be built of sequences of messages that lead to
> incorrect results or failures. For example {{ADDREPLICA}} followed by
> {{CREATEALIAS}} followed by {{DELETEALIAS}}, could see alias creation and
> deletion reordered, making no sense.
> I wasn’t able to come up with a realistic production example that would be
> impacted by this issue (doesn't mean one doesn't exist!).
--
This message was sent by Atlassian Jira
[jira] [Updated] (SOLR-14502) increase bin/solr's post kill sleep
[
https://issues.apache.org/jira/browse/SOLR-14502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-14502:
---
Fix Version/s: 8.6
master (9.0)
> increase bin/solr's post kill sleep
> ---
>
> Key: SOLR-14502
> URL: https://issues.apache.org/jira/browse/SOLR-14502
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Fix For: master (9.0), 8.6
>
> Attachments: SOLR-14502.patch
>
>
> Currently e.g.
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/solr/bin/solr#L863
> we wait for one second after the {{kill -9}} before re-checking if the
> process still exists.
> We've seen a few cases where the {{kill -9}} succeeded but only slightly
> after the one second interval. So this ticket here proposes to increase the
> interval from 1s to (say) 10s.
--
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-14584) solr.in.cmd and solr.in.sh still reference obsolete jks files
[ https://issues.apache.org/jira/browse/SOLR-14584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke resolved SOLR-14584. Fix Version/s: 8.6 master (9.0) Assignee: Christine Poerschke Resolution: Fixed Thanks [~arencambre]! > solr.in.cmd and solr.in.sh still reference obsolete jks files > - > > Key: SOLR-14584 > URL: https://issues.apache.org/jira/browse/SOLR-14584 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: 8.5.2 >Reporter: Aren Cambre >Assignee: Christine Poerschke >Priority: Major > Labels: easyfix > Fix For: master (9.0), 8.6 > > Time Spent: 0.5h > Remaining Estimate: 0h > > When following the Enabling SSL documentation > ([https://lucene.apache.org/solr/guide/8_5/enabling-ssl.html]), the end > result is an error if you miss a critical detail: that you need to change the > *.jks* file extension in two lines to *.p12*. > Please update the default *bin/solr.in.cmd* and *bin/solr.in.sh* files to > reference *p12* files. It appears that the JKS format is obsolete, so there's > no reason to reference those by default. -- 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-14502) increase bin/solr's post kill sleep
[
https://issues.apache.org/jira/browse/SOLR-14502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143053#comment-17143053
]
ASF subversion and git services commented on SOLR-14502:
Commit 2b728551c8624d7004b0cee74db1554c660a0830 in lucene-solr's branch
refs/heads/branch_8x from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=2b72855 ]
SOLR-14502: increase bin/solr's post kill sleep (from 1s to 10s)
> increase bin/solr's post kill sleep
> ---
>
> Key: SOLR-14502
> URL: https://issues.apache.org/jira/browse/SOLR-14502
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-14502.patch
>
>
> Currently e.g.
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/solr/bin/solr#L863
> we wait for one second after the {{kill -9}} before re-checking if the
> process still exists.
> We've seen a few cases where the {{kill -9}} succeeded but only slightly
> after the one second interval. So this ticket here proposes to increase the
> interval from 1s to (say) 10s.
--
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-14502) increase bin/solr's post kill sleep
[
https://issues.apache.org/jira/browse/SOLR-14502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143049#comment-17143049
]
ASF subversion and git services commented on SOLR-14502:
Commit 710fe3a107e91eb7f15fd23df455341168929747 in lucene-solr's branch
refs/heads/master from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=710fe3a ]
SOLR-14502: increase bin/solr's post kill sleep (from 1s to 10s)
> increase bin/solr's post kill sleep
> ---
>
> Key: SOLR-14502
> URL: https://issues.apache.org/jira/browse/SOLR-14502
> Project: Solr
> Issue Type: Task
>Reporter: Christine Poerschke
>Assignee: Christine Poerschke
>Priority: Minor
> Attachments: SOLR-14502.patch
>
>
> Currently e.g.
> https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.5.1/solr/bin/solr#L863
> we wait for one second after the {{kill -9}} before re-checking if the
> process still exists.
> We've seen a few cases where the {{kill -9}} succeeded but only slightly
> after the one second interval. So this ticket here proposes to increase the
> interval from 1s to (say) 10s.
--
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-14584) solr.in.cmd and solr.in.sh still reference obsolete jks files
[ https://issues.apache.org/jira/browse/SOLR-14584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143043#comment-17143043 ] ASF subversion and git services commented on SOLR-14584: Commit 57fdb91f6ffb1076b373b091643aae287b82eb90 in lucene-solr's branch refs/heads/branch_8x from Aren Cambre [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=57fdb91 ] fixes SOLR-14584 > solr.in.cmd and solr.in.sh still reference obsolete jks files > - > > Key: SOLR-14584 > URL: https://issues.apache.org/jira/browse/SOLR-14584 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: 8.5.2 >Reporter: Aren Cambre >Priority: Major > Labels: easyfix > Time Spent: 0.5h > Remaining Estimate: 0h > > When following the Enabling SSL documentation > ([https://lucene.apache.org/solr/guide/8_5/enabling-ssl.html]), the end > result is an error if you miss a critical detail: that you need to change the > *.jks* file extension in two lines to *.p12*. > Please update the default *bin/solr.in.cmd* and *bin/solr.in.sh* files to > reference *p12* files. It appears that the JKS format is obsolete, so there's > no reason to reference those by default. -- 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-14584) solr.in.cmd and solr.in.sh still reference obsolete jks files
[ https://issues.apache.org/jira/browse/SOLR-14584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143045#comment-17143045 ] ASF subversion and git services commented on SOLR-14584: Commit 35e6fa33a2351cd86c269656c06e5b674fe9ca6a in lucene-solr's branch refs/heads/branch_8x from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=35e6fa3 ] SOLR-14584: CHANGES.txt entry SOLR-14584: Correct SOLR_SSL_KEY_STORE and SOLR_SSL_TRUST_STORE example comments in solr.in.sh and solr.in.cmd files (Aren Cambre via Christine Poerschke) Closes #1597 > solr.in.cmd and solr.in.sh still reference obsolete jks files > - > > Key: SOLR-14584 > URL: https://issues.apache.org/jira/browse/SOLR-14584 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: 8.5.2 >Reporter: Aren Cambre >Priority: Major > Labels: easyfix > Time Spent: 0.5h > Remaining Estimate: 0h > > When following the Enabling SSL documentation > ([https://lucene.apache.org/solr/guide/8_5/enabling-ssl.html]), the end > result is an error if you miss a critical detail: that you need to change the > *.jks* file extension in two lines to *.p12*. > Please update the default *bin/solr.in.cmd* and *bin/solr.in.sh* files to > reference *p12* files. It appears that the JKS format is obsolete, so there's > no reason to reference those by default. -- 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-14584) solr.in.cmd and solr.in.sh still reference obsolete jks files
[ https://issues.apache.org/jira/browse/SOLR-14584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143044#comment-17143044 ] ASF subversion and git services commented on SOLR-14584: Commit 35e6fa33a2351cd86c269656c06e5b674fe9ca6a in lucene-solr's branch refs/heads/branch_8x from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=35e6fa3 ] SOLR-14584: CHANGES.txt entry SOLR-14584: Correct SOLR_SSL_KEY_STORE and SOLR_SSL_TRUST_STORE example comments in solr.in.sh and solr.in.cmd files (Aren Cambre via Christine Poerschke) Closes #1597 > solr.in.cmd and solr.in.sh still reference obsolete jks files > - > > Key: SOLR-14584 > URL: https://issues.apache.org/jira/browse/SOLR-14584 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Affects Versions: 8.5.2 >Reporter: Aren Cambre >Priority: Major > Labels: easyfix > Time Spent: 0.5h > Remaining Estimate: 0h > > When following the Enabling SSL documentation > ([https://lucene.apache.org/solr/guide/8_5/enabling-ssl.html]), the end > result is an error if you miss a critical detail: that you need to change the > *.jks* file extension in two lines to *.p12*. > Please update the default *bin/solr.in.cmd* and *bin/solr.in.sh* files to > reference *p12* files. It appears that the JKS format is obsolete, so there's > no reason to reference those by default. -- 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] asfgit closed pull request #1597: SOLR-14584: replace obsolete jks references with p12 references
asfgit closed pull request #1597: URL: https://github.com/apache/lucene-solr/pull/1597 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
