[GitHub] [lucene-solr] epugh merged pull request #2215: SOLR-14067: v3 Create /contrib/scripting module with ScriptingUpdateProcessor
epugh merged pull request #2215: URL: https://github.com/apache/lucene-solr/pull/2215 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-operator] HoustonPutman merged pull request #191: Make docs stable based on the last version, store in Github Pages.
HoustonPutman merged pull request #191: URL: https://github.com/apache/lucene-solr-operator/pull/191 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15100) add ConfigSetService extension ability
[ https://issues.apache.org/jira/browse/SOLR-15100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bai sui updated SOLR-15100: --- Priority: Minor (was: Major) > add ConfigSetService extension ability > -- > > Key: SOLR-15100 > URL: https://issues.apache.org/jira/browse/SOLR-15100 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Schema and Analysis >Affects Versions: 8.7 >Reporter: bai sui >Priority: Minor > > I want to load schema and solrconfig configuration form DB，that need to > customize the SolrResourceLoader for my own。 > customized SolrResourceLoader will be create from > ConfigSetService.createCoreResourceLoader() method。 > so i want to modify the static method ConfigSetService.createConfigSetService > in that I can define the customized class name of ConfigSetService in > solr.xml and create it in the method -- 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-15100) add ConfigSetService extension ability
bai sui created SOLR-15100: -- Summary: add ConfigSetService extension ability Key: SOLR-15100 URL: https://issues.apache.org/jira/browse/SOLR-15100 Project: Solr Issue Type: Improvement Security Level: Public (Default Security Level. Issues are Public) Components: Schema and Analysis Affects Versions: 8.7 Reporter: bai sui I want to load schema and solrconfig configuration form DB，that need to customize the SolrResourceLoader for my own。 customized SolrResourceLoader will be create from ConfigSetService.createCoreResourceLoader() method。 so i want to modify the static method ConfigSetService.createConfigSetService in that I can define the customized class name of ConfigSetService in solr.xml and create it in the method -- 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-operator] thelabdude merged pull request #189: Override Prometheus exporter config XML via a user-supplied ConfigMap
thelabdude merged pull request #189: URL: https://github.com/apache/lucene-solr-operator/pull/189 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] dweiss commented on a change in pull request #2229: LUCENE-9688: Hunspell: consider prefix's continuation flags when applying suffix
dweiss commented on a change in pull request #2229:
URL: https://github.com/apache/lucene-solr/pull/2229#discussion_r562462937
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/Stemmer.java
##
@@ -588,6 +585,12 @@ private boolean checkCondition(
return stems;
}
+ private boolean isFlagAppendedByAffix(int affixId, char flag) {
+if (affixId < 0) return false;
Review comment:
Add curly braces. I know, it's verbose but some folks on this list even
went as far as to require it (the formatter doesn't care).
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] dweiss commented on a change in pull request #2229: LUCENE-9688: Hunspell: consider prefix's continuation flags when applying suffix
dweiss commented on a change in pull request #2229: URL: https://github.com/apache/lucene-solr/pull/2229#discussion_r562463263 ## File path: lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/Stemmer.java ## @@ -472,9 +472,9 @@ private boolean checkCondition( * @param strippedWord Word the affix has been removed and the strip added * @param length valid length of stripped word * @param affix HunspellAffix representing the affix rule itself - * @param prefixFlag when we already stripped a prefix, we cant simply recurse and check the - * suffix, unless both are compatible so we must check dictionary form against both to add it - * as a stem! + * @param prefixId when we already stripped a prefix, we cant simply recurse and check the suffix, Review comment: cant -> can't (I realize it's not you, but maybe correct while we're 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-operator] HoustonPutman merged pull request #190: Use main branch instead of master branch.
HoustonPutman merged pull request #190: URL: https://github.com/apache/lucene-solr-operator/pull/190 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] dweiss commented on a change in pull request #2228: LUCENE-9684: Hunspell: support COMPOUNDRULE
dweiss commented on a change in pull request #2228:
URL: https://github.com/apache/lucene-solr/pull/2228#discussion_r562468628
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/CompoundRule.java
##
@@ -0,0 +1,105 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.analysis.hunspell;
+
+import java.util.List;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.IntsRef;
+
+class CompoundRule {
+ private final char[] data;
Review comment:
I wonder if keeping char[] instead of the string itself buys us anything
here. Strings can use more efficient storage than on newer JVMs (compact
strings) and using charAt instead of array accesses is pretty much the same?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-9669) N-2 compatibility for file formats
[ https://issues.apache.org/jira/browse/LUCENE-9669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer resolved LUCENE-9669. - Resolution: Fixed > N-2 compatibility for file formats > -- > > Key: LUCENE-9669 > URL: https://issues.apache.org/jira/browse/LUCENE-9669 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Simon Willnauer >Assignee: Simon Willnauer >Priority: Major > Fix For: master (9.0) > > Time Spent: 3.5h > Remaining Estimate: 0h > > Currently Lucene supports reading and writing indices that have been > created with the current or previous (N-1) version of Lucene. Lucene > refuses to open an index created by N-2 or earlier versions. > I would like to propose that Lucene adds support for opening indices > created by version N-2 in read-only mode. Here's what I have in mind: > - Read-only support. You can open a reader on an index created by > version N-2, but you cannot open an IndexWriter on it, meaning that > you can neither delete, update, add documents or force-merge N-2 > indices. > - File-format compatibility only. File-format compatibility enables > reading the content of old indices, but not more. Everything that is > done on top of file formats like analysis or the encoding of length > normalization factors is not guaranteed and only supported on a > best-effort basis. > The reason I came up with these limitations is because I wanted to > make the scope minimal in order to retain Lucene's ability to move > forward. If there is consensus to move forward with this, I would like > to target Lucene 9.0 with this change. > This is a follow-up of the mailinglist thread > [here|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3ccaahmpkg1bd9rtmvfr4jweygyaxwz5osy1hv9ubzks0fhsfn...@mail.gmail.com%3E] > -- 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-15011) /admin/logging handler should be able to configure logs on all nodes
[ https://issues.apache.org/jira/browse/SOLR-15011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270013#comment-17270013 ] Nazerke Seidan commented on SOLR-15011: --- [~dsmiley], I have created a PR. Please, take a look, thanks. > /admin/logging handler should be able to configure logs on all nodes > > > Key: SOLR-15011 > URL: https://issues.apache.org/jira/browse/SOLR-15011 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: logging >Reporter: David Smiley >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The LoggingHandler registered at /admin/logging can configure log levels for > the current node. This is nice but in SolrCloud, what's needed is an ability > to change the level for _all_ nodes in the cluster. I propose that this be a > parameter name "distrib" defaulting to SolrCloud mode's status. An admin UI > could have a checkbox for it. I don't propose that the read operations be > changed -- they can continue to just look at the node you are hitting. -- 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] donnerpeter commented on a change in pull request #2229: LUCENE-9688: Hunspell: consider prefix's continuation flags when applying suffix
donnerpeter commented on a change in pull request #2229:
URL: https://github.com/apache/lucene-solr/pull/2229#discussion_r562483637
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/Stemmer.java
##
@@ -588,6 +585,12 @@ private boolean checkCondition(
return stems;
}
+ private boolean isFlagAppendedByAffix(int affixId, char flag) {
+if (affixId < 0) return false;
Review comment:
Curly braces and 2 more lines? Oh pity, I love conciseness so much :(
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] donnerpeter commented on a change in pull request #2228: LUCENE-9684: Hunspell: support COMPOUNDRULE
donnerpeter commented on a change in pull request #2228:
URL: https://github.com/apache/lucene-solr/pull/2228#discussion_r562485090
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/CompoundRule.java
##
@@ -0,0 +1,105 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.analysis.hunspell;
+
+import java.util.List;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.IntsRef;
+
+class CompoundRule {
+ private final char[] data;
Review comment:
Memory shouldn't be of much concern, as AFAIK there are usually very few
rules. Array access is a bit shorter in code, so I'd prefer to leave it.
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] donnerpeter commented on pull request #2228: LUCENE-9684: Hunspell: support COMPOUNDRULE
donnerpeter commented on pull request #2228: URL: https://github.com/apache/lucene-solr/pull/2228#issuecomment-765252494 > I didn't verify it against what hunspell actually does (I trust you did it :). Sure, I did :) 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] dweiss commented on a change in pull request #2229: LUCENE-9688: Hunspell: consider prefix's continuation flags when applying suffix
dweiss commented on a change in pull request #2229:
URL: https://github.com/apache/lucene-solr/pull/2229#discussion_r562486256
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/Stemmer.java
##
@@ -588,6 +585,12 @@ private boolean checkCondition(
return stems;
}
+ private boolean isFlagAppendedByAffix(int affixId, char flag) {
+if (affixId < 0) return false;
Review comment:
The discussion of whether braces in single-line statements in
if/while/for loops are needed or not
is like religion - you can't end it, once started... I'm just relaying what
has been said
on the mailing list after the formatter folded code like this:
```
if (foo)
doSomething()
else
doSomethingElse()
```
Privately, I don't have a strong opinion. Depends on the context where it's
at, I guess.
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] dweiss commented on a change in pull request #2228: LUCENE-9684: Hunspell: support COMPOUNDRULE
dweiss commented on a change in pull request #2228:
URL: https://github.com/apache/lucene-solr/pull/2228#discussion_r562486787
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/CompoundRule.java
##
@@ -0,0 +1,105 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.lucene.analysis.hunspell;
+
+import java.util.List;
+import org.apache.lucene.util.BytesRef;
+import org.apache.lucene.util.IntsRef;
+
+class CompoundRule {
+ private final char[] data;
Review comment:
ok.
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] donnerpeter commented on a change in pull request #2229: LUCENE-9688: Hunspell: consider prefix's continuation flags when applying suffix
donnerpeter commented on a change in pull request #2229:
URL: https://github.com/apache/lucene-solr/pull/2229#discussion_r562493566
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/Stemmer.java
##
@@ -588,6 +585,12 @@ private boolean checkCondition(
return stems;
}
+ private boolean isFlagAppendedByAffix(int affixId, char flag) {
+if (affixId < 0) return false;
Review comment:
In that case I'd also put braces (although I've seen people who don't).
But my case is "then-branch is a simple `return` on the same line". Are braces
also required in this case? And separate lines, like this?
```
if (affixId < 0) {
return;
}
```
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] dweiss commented on a change in pull request #2229: LUCENE-9688: Hunspell: consider prefix's continuation flags when applying suffix
dweiss commented on a change in pull request #2229:
URL: https://github.com/apache/lucene-solr/pull/2229#discussion_r562496757
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/Stemmer.java
##
@@ -588,6 +585,12 @@ private boolean checkCondition(
return stems;
}
+ private boolean isFlagAppendedByAffix(int affixId, char flag) {
+if (affixId < 0) return false;
Review comment:
Required is not the right word... Perhaps... advised. :) You are
entitled to your own opinion (at least as long as this passes precommit
checks!) - like I said, I relayed what's been mentioned on the mailing list.
Some people just put braces everywhere and they are used to this consistency,
even if it adds verbosity.
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] donnerpeter commented on a change in pull request #2229: LUCENE-9688: Hunspell: consider prefix's continuation flags when applying suffix
donnerpeter commented on a change in pull request #2229:
URL: https://github.com/apache/lucene-solr/pull/2229#discussion_r562524364
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/Stemmer.java
##
@@ -588,6 +585,12 @@ private boolean checkCondition(
return stems;
}
+ private boolean isFlagAppendedByAffix(int affixId, char flag) {
+if (affixId < 0) return false;
Review comment:
Would it be acceptable to reformat the code when such a demand appears,
or after I'm finished with these improvements? These "some people" might never
need to look into Hunspell code.
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] donnerpeter commented on pull request #2228: LUCENE-9684: Hunspell: support COMPOUNDRULE
donnerpeter commented on pull request #2228: URL: https://github.com/apache/lucene-solr/pull/2228#issuecomment-765300690 How do we proceed here? Should anyone else review this? 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] [Reopened] (SOLR-15100) add ConfigSetService extension ability
[ https://issues.apache.org/jira/browse/SOLR-15100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bai sui reopened SOLR-15100: > add ConfigSetService extension ability > -- > > Key: SOLR-15100 > URL: https://issues.apache.org/jira/browse/SOLR-15100 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Schema and Analysis >Affects Versions: 8.7 >Reporter: bai sui >Priority: Minor > > I want to load schema and solrconfig configuration form DB，that need to > customize the SolrResourceLoader for my own。 > customized SolrResourceLoader will be create from > ConfigSetService.createCoreResourceLoader() method。 > so i want to modify the static method ConfigSetService.createConfigSetService > in that I can define the customized class name of ConfigSetService in > solr.xml and create it in the method -- 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-15100) add ConfigSetService extension ability
[ https://issues.apache.org/jira/browse/SOLR-15100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bai sui resolved SOLR-15100. Resolution: Fixed > add ConfigSetService extension ability > -- > > Key: SOLR-15100 > URL: https://issues.apache.org/jira/browse/SOLR-15100 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Schema and Analysis >Affects Versions: 8.7 >Reporter: bai sui >Priority: Minor > > I want to load schema and solrconfig configuration form DB，that need to > customize the SolrResourceLoader for my own。 > customized SolrResourceLoader will be create from > ConfigSetService.createCoreResourceLoader() method。 > so i want to modify the static method ConfigSetService.createConfigSetService > in that I can define the customized class name of ConfigSetService in > solr.xml and create it in the method -- 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] dweiss commented on pull request #2228: LUCENE-9684: Hunspell: support COMPOUNDRULE
dweiss commented on pull request #2228: URL: https://github.com/apache/lucene-solr/pull/2228#issuecomment-765324334 No, I'll commit it in. I have an unrelated day job so expect some delays. 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-9684) Hunspell: support COMPOUNDRULE
[ https://issues.apache.org/jira/browse/LUCENE-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270060#comment-17270060 ] ASF subversion and git services commented on LUCENE-9684: - Commit d7968130c3f5d7166c10756c37b5ed644414cd1d in lucene-solr's branch refs/heads/master from Peter Gromov [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=d796813 ] LUCENE-9684: Hunspell: support COMPOUNDRULE (#2228) > Hunspell: support COMPOUNDRULE > -- > > Key: LUCENE-9684 > URL: https://issues.apache.org/jira/browse/LUCENE-9684 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Peter Gromov >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > e.g. for ordinal numbers in en-US dictionary (1st, 42nd, etc) -- 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] dweiss commented on a change in pull request #2229: LUCENE-9688: Hunspell: consider prefix's continuation flags when applying suffix
dweiss commented on a change in pull request #2229:
URL: https://github.com/apache/lucene-solr/pull/2229#discussion_r562555997
##
File path:
lucene/analysis/common/src/java/org/apache/lucene/analysis/hunspell/Stemmer.java
##
@@ -588,6 +585,12 @@ private boolean checkCondition(
return stems;
}
+ private boolean isFlagAppendedByAffix(int affixId, char flag) {
+if (affixId < 0) return false;
Review comment:
I think consistency in those braces (over verbosity) is a good rule in
general, but ok.
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] dweiss merged pull request #2229: LUCENE-9688: Hunspell: consider prefix's continuation flags when applying suffix
dweiss merged pull request #2229: URL: https://github.com/apache/lucene-solr/pull/2229 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-9688) Hunspell: consider prefix's continuation flags when applying suffix
[ https://issues.apache.org/jira/browse/LUCENE-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270061#comment-17270061 ] ASF subversion and git services commented on LUCENE-9688: - Commit 0a1a3f4c4095bf5258e5898c2b23658747f12bba in lucene-solr's branch refs/heads/master from Peter Gromov [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=0a1a3f4 ] LUCENE-9688: Hunspell: consider prefix's continuation flags when applying suffix (#2229) > Hunspell: consider prefix's continuation flags when applying suffix > --- > > Key: LUCENE-9688 > URL: https://issues.apache.org/jira/browse/LUCENE-9688 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Peter Gromov >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > aff: > SFX s Y 1 > SFX s 0 s . > PFX p Y 1 > PFX p 0 0/s . > dic: > calorie/p > "calories" should be accepted -- 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-9684) Hunspell: support COMPOUNDRULE
[ https://issues.apache.org/jira/browse/LUCENE-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Gromov resolved LUCENE-9684. -- Resolution: Fixed > Hunspell: support COMPOUNDRULE > -- > > Key: LUCENE-9684 > URL: https://issues.apache.org/jira/browse/LUCENE-9684 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Peter Gromov >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > e.g. for ordinal numbers in en-US dictionary (1st, 42nd, etc) -- 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-9688) Hunspell: consider prefix's continuation flags when applying suffix
[ https://issues.apache.org/jira/browse/LUCENE-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Gromov resolved LUCENE-9688. -- Resolution: Fixed > Hunspell: consider prefix's continuation flags when applying suffix > --- > > Key: LUCENE-9688 > URL: https://issues.apache.org/jira/browse/LUCENE-9688 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Peter Gromov >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > aff: > SFX s Y 1 > SFX s 0 s . > PFX p Y 1 > PFX p 0 0/s . > dic: > calorie/p > "calories" should be accepted -- 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] bruno-roustant commented on a change in pull request #2213: LUCENE-9663: Adding compression to terms dict from SortedSet/Sorted DocValues
bruno-roustant commented on a change in pull request #2213:
URL: https://github.com/apache/lucene-solr/pull/2213#discussion_r562555734
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene80/Lucene80DocValuesConsumer.java
##
@@ -731,7 +731,22 @@ private void doAddSortedField(FieldInfo field,
DocValuesProducer valuesProducer)
meta.writeLong(data.getFilePointer() - start); // ordsLength
}
-addTermsDict(DocValues.singleton(valuesProducer.getSorted(field)));
+int valuesCount = values.getValueCount();
+switch (mode) {
Review comment:
Could we have a "if" instead of a switch? The if could call the right
method on the SortedSetDocValues singleton.
(for a switch, we should handle the "default" case with an exception but I
don't think it useful here)
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene80/Lucene80DocValuesConsumer.java
##
@@ -791,6 +806,107 @@ private void addTermsDict(SortedSetDocValues values)
throws IOException {
writeTermsIndex(values);
}
+ private void addCompressedTermsDict(SortedSetDocValues values) throws
IOException {
+final long size = values.getValueCount();
+meta.writeVLong(size);
+meta.writeInt(Lucene80DocValuesFormat.TERMS_DICT_BLOCK_LZ4_CODE);
+
+ByteBuffersDataOutput addressBuffer = new ByteBuffersDataOutput();
+ByteBuffersIndexOutput addressOutput =
+new ByteBuffersIndexOutput(addressBuffer, "temp", "temp");
+meta.writeInt(DIRECT_MONOTONIC_BLOCK_SHIFT);
+long numBlocks =
+(size + Lucene80DocValuesFormat.TERMS_DICT_BLOCK_LZ4_MASK)
+>>> Lucene80DocValuesFormat.TERMS_DICT_BLOCK_LZ4_SHIFT;
+DirectMonotonicWriter writer =
+DirectMonotonicWriter.getInstance(
+meta, addressOutput, numBlocks, DIRECT_MONOTONIC_BLOCK_SHIFT);
+
+LZ4.FastCompressionHashTable ht = new LZ4.FastCompressionHashTable();
+ByteArrayDataOutput bufferedOutput = new
ByteArrayDataOutput(termsDictBuffer);
+long ord = 0;
+long start = data.getFilePointer();
+int maxLength = 0;
+TermsEnum iterator = values.termsEnum();
+int maxBlockLength = 0;
+BytesRefBuilder previous = new BytesRefBuilder();
+for (BytesRef term = iterator.next(); term != null; term =
iterator.next()) {
+ int termLength = term.length;
+ if ((ord & Lucene80DocValuesFormat.TERMS_DICT_BLOCK_LZ4_MASK) == 0) {
+if (bufferedOutput.getPosition() > 0) {
+ int uncompressedLength = bufferedOutput.getPosition();
+ data.writeVInt(uncompressedLength);
+ maxBlockLength = Math.max(maxBlockLength, uncompressedLength);
+ long before = data.getFilePointer();
+ // Compress block
+ LZ4.compress(termsDictBuffer, 0, uncompressedLength, data, ht);
+ int compressedLength = (int) (data.getFilePointer() - before);
+ // Corner case: Compressed length might be bigger than un-compressed
length.
+ maxBlockLength = Math.max(maxBlockLength, compressedLength);
+ bufferedOutput.reset(termsDictBuffer);
+}
+
+writer.add(data.getFilePointer() - start);
+data.writeVInt(termLength);
+data.writeBytes(term.bytes, term.offset, termLength);
+ } else {
+final int prefixLength = StringHelper.bytesDifference(previous.get(),
term);
+final int suffixLength = term.length - prefixLength;
+assert suffixLength > 0; // terms are unique
+int reservedSize = suffixLength + 11; // 1 byte + 2 vint.
+bufferedOutput = maybeGrowBuffer(bufferedOutput, reservedSize);
+bufferedOutput.writeByte(
+(byte) (Math.min(prefixLength, 15) | (Math.min(15, suffixLength -
1) << 4)));
+
+if (prefixLength >= 15) {
+ bufferedOutput.writeVInt(prefixLength - 15);
+}
+if (suffixLength >= 16) {
+ bufferedOutput.writeVInt(suffixLength - 16);
+}
+bufferedOutput.writeBytes(term.bytes, term.offset + prefixLength,
suffixLength);
+ }
+ maxLength = Math.max(maxLength, termLength);
+ previous.copyBytes(term);
+ ++ord;
+}
+
+// Compress and write out the last block
+if (bufferedOutput.getPosition() > 0) {
+ int uncompressedLength = bufferedOutput.getPosition();
+ data.writeVInt(uncompressedLength);
+ maxBlockLength = Math.max(maxBlockLength, uncompressedLength);
+ long before = data.getFilePointer();
+ LZ4.compress(termsDictBuffer, 0, uncompressedLength, data, ht);
+ int compressedLength = (int) (data.getFilePointer() - before);
+ maxBlockLength = Math.max(maxBlockLength, compressedLength);
+}
+
+writer.finish();
+meta.writeInt(maxLength);
+// Write one more int for storing max block length. For compressed terms
dict only.
+meta.writeInt(maxBlockLength);
+meta.writeLong(start);
+meta.writeLong(data.getFilePointer() - start);
+start = data.getFilePointer(
[GitHub] [lucene-solr] bruno-roustant commented on a change in pull request #2213: LUCENE-9663: Adding compression to terms dict from SortedSet/Sorted DocValues
bruno-roustant commented on a change in pull request #2213:
URL: https://github.com/apache/lucene-solr/pull/2213#discussion_r562555734
##
File path:
lucene/core/src/java/org/apache/lucene/codecs/lucene80/Lucene80DocValuesConsumer.java
##
@@ -731,7 +731,22 @@ private void doAddSortedField(FieldInfo field,
DocValuesProducer valuesProducer)
meta.writeLong(data.getFilePointer() - start); // ordsLength
}
-addTermsDict(DocValues.singleton(valuesProducer.getSorted(field)));
+int valuesCount = values.getValueCount();
+switch (mode) {
Review comment:
Could we have a "if" instead of a switch? The if could call the right
method on the SortedSetDocValues singleton.
(for a switch, we should handle the "default" case with an exception but I
don't think it's useful 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
[jira] [Created] (LUCENE-9690) Hunspell: support special title-case for words with apostrophe
Peter Gromov created LUCENE-9690: Summary: Hunspell: support special title-case for words with apostrophe Key: LUCENE-9690 URL: https://issues.apache.org/jira/browse/LUCENE-9690 Project: Lucene - Core Issue Type: Sub-task Reporter: Peter Gromov When checking French L'AFRIQUE, consider not only L'afrique, but also L'Afrique -- 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] donnerpeter opened a new pull request #2235: LUCENE-9690: Hunspell: support special title-case for words with apostrophe
donnerpeter opened a new pull request #2235: URL: https://github.com/apache/lucene-solr/pull/2235 # Description When checking French L'AFRIQUE, consider not only L'afrique, but also L'Afrique # Solution When there's an apostrophe, try a case variant with an uppercase after it, just like Hunspell does (https://github.com/hunspell/hunspell/blob/master/src/hunspell/hunspell.cxx#L547) # Tests Enhanced `allcaps` test for both stemmer and spellchecker (as the case processing logic is duplicated there) # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `master` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9691) Hunspell: support trailing comments on aff option lines
Peter Gromov created LUCENE-9691: Summary: Hunspell: support trailing comments on aff option lines Key: LUCENE-9691 URL: https://issues.apache.org/jira/browse/LUCENE-9691 Project: Lucene - Core Issue Type: Sub-task Reporter: Peter Gromov e.g. # Testing also whitespace and comments. OCONV 2 # space, space OCONV a A # tab, space, space OCONV b B # tab, tab, space -- 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-9691) Hunspell: support trailing comments on aff option lines
[ https://issues.apache.org/jira/browse/LUCENE-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Gromov updated LUCENE-9691: - Description: e.g. ``` # Testing also whitespace and comments. OCONV 2 # space, space OCONV a A # tab, space, space OCONV b B # tab, tab, space ``` was: e.g. # Testing also whitespace and comments. OCONV 2 # space, space OCONV a A # tab, space, space OCONV b B # tab, tab, space > Hunspell: support trailing comments on aff option lines > --- > > Key: LUCENE-9691 > URL: https://issues.apache.org/jira/browse/LUCENE-9691 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Peter Gromov >Priority: Major > > e.g. > ``` > # Testing also whitespace and comments. > OCONV 2 # space, space > OCONV a A # tab, space, space > OCONV b B # tab, tab, space > ``` -- 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-9691) Hunspell: support trailing comments on aff option lines
[
https://issues.apache.org/jira/browse/LUCENE-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Gromov updated LUCENE-9691:
-
Description:
e.g.
{{
# Testing also whitespace and comments.
OCONV 2 # space, space
OCONV a A # tab, space, space
OCONV b B # tab, tab, space
}}
was:
e.g.
```
# Testing also whitespace and comments.
OCONV 2 # space, space
OCONV a A # tab, space, space
OCONV b B # tab, tab, space
```
> Hunspell: support trailing comments on aff option lines
> ---
>
> Key: LUCENE-9691
> URL: https://issues.apache.org/jira/browse/LUCENE-9691
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Peter Gromov
>Priority: Major
>
> e.g.
> {{
> # Testing also whitespace and comments.
> OCONV 2 # space, space
> OCONV a A # tab, space, space
> OCONV b B # tab, tab, space
> }}
--
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-9691) Hunspell: support trailing comments on aff option lines
[
https://issues.apache.org/jira/browse/LUCENE-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Gromov updated LUCENE-9691:
-
Description:
e.g.
{code:java}
# Testing also whitespace and comments.
OCONV 2 # space, space
OCONV a A # tab, space, space
OCONV b B # tab, tab, space
{code}
was:
e.g.
{{# Testing also whitespace and comments.
OCONV 2 # space, space
OCONV a A # tab, space, space
OCONV b B # tab, tab, space}}
> Hunspell: support trailing comments on aff option lines
> ---
>
> Key: LUCENE-9691
> URL: https://issues.apache.org/jira/browse/LUCENE-9691
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Peter Gromov
>Priority: Major
>
> e.g.
> {code:java}
> # Testing also whitespace and comments.
> OCONV 2 # space, space
> OCONV a A # tab, space, space
> OCONV b B # tab, tab, space
> {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] [Updated] (LUCENE-9691) Hunspell: support trailing comments on aff option lines
[
https://issues.apache.org/jira/browse/LUCENE-9691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Gromov updated LUCENE-9691:
-
Description:
e.g.
{{# Testing also whitespace and comments.
OCONV 2 # space, space
OCONV a A # tab, space, space
OCONV b B # tab, tab, space}}
was:
e.g.
{{
# Testing also whitespace and comments.
OCONV 2 # space, space
OCONV a A # tab, space, space
OCONV b B # tab, tab, space
}}
> Hunspell: support trailing comments on aff option lines
> ---
>
> Key: LUCENE-9691
> URL: https://issues.apache.org/jira/browse/LUCENE-9691
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Peter Gromov
>Priority: Major
>
> e.g.
> {{# Testing also whitespace and comments.
> OCONV 2 # space, space
> OCONV a A # tab, space, space
> OCONV b B # tab, tab, space}}
--
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] donnerpeter opened a new pull request #2236: LUCENE-9691: Hunspell: support trailing comments on aff option lines
donnerpeter opened a new pull request #2236: URL: https://github.com/apache/lucene-solr/pull/2236 plus cleanup & deduplicate parsing # Description e.g. ``` # Testing also whitespace and comments. OCONV 2 # space, space OCONV a A # tab, space, space OCONV b B # tab, tab, space ``` # Solution Deduplicate the code where an aff string is split into parts by whitespace, allow for # in the first unexpected part there # Tests Expanded `conv` test # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [x] I have run `./gradlew check`. - [x] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (LUCENE-9692) Hunspell: extract Stemmer.stripAffix from similar code in prefix/suffix processing
Peter Gromov created LUCENE-9692: Summary: Hunspell: extract Stemmer.stripAffix from similar code in prefix/suffix processing Key: LUCENE-9692 URL: https://issues.apache.org/jira/browse/LUCENE-9692 Project: Lucene - Core Issue Type: Sub-task Reporter: Peter Gromov -- 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] donnerpeter opened a new pull request #2237: LUCENE-9692: Hunspell: extract Stemmer.stripAffix from similar code in prefix/suffix processing
donnerpeter opened a new pull request #2237: URL: https://github.com/apache/lucene-solr/pull/2237 # Description The code is too similar, can be deduplicated # Solution Extract a method, cleanup # Tests Just a refactoring, no tests # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [x] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] cpoerschke commented on pull request #2210: SOLR-15073: Fix ClassCastException in SystemInfoHandler.getSecurityInfo
cpoerschke commented on pull request #2210: URL: https://github.com/apache/lucene-solr/pull/2210#issuecomment-765355217 Reviewed by Ishan as per https://lists.apache.org/thread.html/rc366c72ef1cbae0518d0c5e39f7029a3caa03a7dd863cbee951d2b2a%40%3Cdev.lucene.apache.org%3E - thank you! 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] cpoerschke merged pull request #2210: SOLR-15073: Fix ClassCastException in SystemInfoHandler.getSecurityInfo
cpoerschke merged pull request #2210: URL: https://github.com/apache/lucene-solr/pull/2210 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] (LUCENE-9693) Hunspell: check that all flags are > 0 and fit char
Peter Gromov created LUCENE-9693: Summary: Hunspell: check that all flags are > 0 and fit char Key: LUCENE-9693 URL: https://issues.apache.org/jira/browse/LUCENE-9693 Project: Lucene - Core Issue Type: Sub-task Reporter: Peter Gromov Hunspell has a similar check -- 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-15073) Unsafe cast in SystemInfoHandler
[ https://issues.apache.org/jira/browse/SOLR-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270094#comment-17270094 ] ASF subversion and git services commented on SOLR-15073: Commit fb88b0268aa0c7f14d77ae425b4851a8bedd2327 in lucene-solr's branch refs/heads/master from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=fb88b02 ] SOLR-15073: Fix ClassCastException in SystemInfoHandler.getSecurityInfo (#2210) > Unsafe cast in SystemInfoHandler > > > Key: SOLR-15073 > URL: https://issues.apache.org/jira/browse/SOLR-15073 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6, 8.7 >Reporter: Nikolay Ivanov >Assignee: Christine Poerschke >Priority: Major > Fix For: 8.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have observed an unsafe cast in > SystemInfoHandler::getSecurityInfo > Is this by design? Currently I have a custom AuthorizationPlugin that > directly implements AuthorizationPlugin interface. With the latest solr > version it is not permitted anymore. A workaround is to extend the > RuleBasedAuthorizationPluginBase, which is not ideal imo. Please share your > thoughts -- 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] donnerpeter opened a new pull request #2238: LUCENE-9693: Hunspell: check that all flags are > 0 and fit char range
donnerpeter opened a new pull request #2238: URL: https://github.com/apache/lucene-solr/pull/2238 # Description Hunspell: check that all flags are > 0 and fit char range, as Hunspell does # Solution 1. Add a corresponding assertion 2. Fix HIDDEN_FLAG serialization bug found by this assertion 3. Use char instead of int to store and pass flags around, because now we can use 0 for an unset flag instead of -1 # Tests No new tests, but some tests failed after implementing step 1 and were fixed in step 2 # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `master` branch. - [x] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Ref Guide](https://github.com/apache/lucene-solr/tree/master/solr/solr-ref-guide) (for Solr changes only). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-15073) Unsafe cast in SystemInfoHandler
[ https://issues.apache.org/jira/browse/SOLR-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270097#comment-17270097 ] ASF subversion and git services commented on SOLR-15073: Commit ec4917c45eaf7dccdcc98fba08484eb24e1ff5f2 in lucene-solr's branch refs/heads/branch_8x from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ec4917c ] SOLR-15073: Fix ClassCastException in SystemInfoHandler.getSecurityInfo (#2210) > Unsafe cast in SystemInfoHandler > > > Key: SOLR-15073 > URL: https://issues.apache.org/jira/browse/SOLR-15073 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6, 8.7 >Reporter: Nikolay Ivanov >Assignee: Christine Poerschke >Priority: Major > Fix For: 8.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have observed an unsafe cast in > SystemInfoHandler::getSecurityInfo > Is this by design? Currently I have a custom AuthorizationPlugin that > directly implements AuthorizationPlugin interface. With the latest solr > version it is not permitted anymore. A workaround is to extend the > RuleBasedAuthorizationPluginBase, which is not ideal imo. Please share your > thoughts -- 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-15073) Unsafe cast in SystemInfoHandler
[ https://issues.apache.org/jira/browse/SOLR-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270104#comment-17270104 ] ASF subversion and git services commented on SOLR-15073: Commit 07d5a6e8b7211858253ca7b7ba840126f0ef07d6 in lucene-solr's branch refs/heads/branch_8_8 from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=07d5a6e ] SOLR-15073: Fix ClassCastException in SystemInfoHandler.getSecurityInfo (#2210) > Unsafe cast in SystemInfoHandler > > > Key: SOLR-15073 > URL: https://issues.apache.org/jira/browse/SOLR-15073 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6, 8.7 >Reporter: Nikolay Ivanov >Assignee: Christine Poerschke >Priority: Major > Fix For: 8.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have observed an unsafe cast in > SystemInfoHandler::getSecurityInfo > Is this by design? Currently I have a custom AuthorizationPlugin that > directly implements AuthorizationPlugin interface. With the latest solr > version it is not permitted anymore. A workaround is to extend the > RuleBasedAuthorizationPluginBase, which is not ideal imo. Please share your > thoughts -- 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-15073) Unsafe cast in SystemInfoHandler
[ https://issues.apache.org/jira/browse/SOLR-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270105#comment-17270105 ] Christine Poerschke commented on SOLR-15073: Thanks [~ichattopadhyaya] for the PR review! As per above the change has been committed to master, branch_8x and branch_8_8 branches. I'll keep this ticket open until it's known if the fix will be included in 8.8.0 or not. If not then the CHANGES.txt entry will need to be moved out of the 8.8.0 section and the "Fix Version" attributes of the JIRA be updated here. > Unsafe cast in SystemInfoHandler > > > Key: SOLR-15073 > URL: https://issues.apache.org/jira/browse/SOLR-15073 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6, 8.7 >Reporter: Nikolay Ivanov >Assignee: Christine Poerschke >Priority: Major > Fix For: 8.8 > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have observed an unsafe cast in > SystemInfoHandler::getSecurityInfo > Is this by design? Currently I have a custom AuthorizationPlugin that > directly implements AuthorizationPlugin interface. With the latest solr > version it is not permitted anymore. A workaround is to extend the > RuleBasedAuthorizationPluginBase, which is not ideal imo. Please share your > thoughts -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-15073) Unsafe cast in SystemInfoHandler
[ https://issues.apache.org/jira/browse/SOLR-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-15073: --- Fix Version/s: master (9.0) > Unsafe cast in SystemInfoHandler > > > Key: SOLR-15073 > URL: https://issues.apache.org/jira/browse/SOLR-15073 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6, 8.7 >Reporter: Nikolay Ivanov >Assignee: Christine Poerschke >Priority: Major > Fix For: 8.8, master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have observed an unsafe cast in > SystemInfoHandler::getSecurityInfo > Is this by design? Currently I have a custom AuthorizationPlugin that > directly implements AuthorizationPlugin interface. With the latest solr > version it is not permitted anymore. A workaround is to extend the > RuleBasedAuthorizationPluginBase, which is not ideal imo. Please share your > thoughts -- 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] dweiss merged pull request #2228: LUCENE-9684: Hunspell: support COMPOUNDRULE
dweiss merged pull request #2228: URL: https://github.com/apache/lucene-solr/pull/2228 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] cpoerschke merged pull request #2196: SOLR-15071: Fix ArrayIndexOutOfBoundsException in contrib/ltr SolrFeatureScorer
cpoerschke merged pull request #2196: URL: https://github.com/apache/lucene-solr/pull/2196 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-15071) Bug on LTR when using solr 8.6.3 - index out of bounds DisiPriorityQueue.add(DisiPriorityQueue.java:102)
[
https://issues.apache.org/jira/browse/SOLR-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270126#comment-17270126
]
ASF subversion and git services commented on SOLR-15071:
Commit 32e95ddb3f2542fbe2cb116ac58453182149f07b in lucene-solr's branch
refs/heads/master from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=32e95dd ]
SOLR-15071: Fix ArrayIndexOutOfBoundsException in contrib/ltr SolrFeatureScorer
(#2196)
> Bug on LTR when using solr 8.6.3 - index out of bounds
> DisiPriorityQueue.add(DisiPriorityQueue.java:102)
>
>
> Key: SOLR-15071
> URL: https://issues.apache.org/jira/browse/SOLR-15071
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 8.6, 8.7
>Reporter: Florin Babes
>Assignee: Christine Poerschke
>Priority: Major
> Labels: ltr
> Fix For: 8.8
>
> Attachments: featurestore+model+sample_documents.zip
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hello,
> We are trying to update Solr from 8.3.1 to 8.6.3. On Solr 8.3.1 we are
> using LTR in production using a MultipleAdditiveTrees model. On Solr 8.6.3
> we receive an error when we try to compute some SolrFeatures. We didn't
> find any pattern of the queries that fail.
> Example:
> We have the following query raw parameters:
> q=lg cx 4k oled 120 hz -> just of many examples
> term_dq=lg cx 4k oled 120 hz
> rq={!ltr model=model reRankDocs=1000 store=feature_store
> efi.term=${term_dq}}
> defType=edismax,
> mm=2<75%
> The features are something like this:
> {
> "name":"similarity_query_fileld_1",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_1 mm=1}${term}"},
> "store":"feature_store"
> },
> {
> "name":"similarity_query_field_2",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_2 mm=5}${term}"},
> "store":"feature_store"
> }
> We are testing ~6300 production queries and for about 1% of them we receive
> that following error message:
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","java.lang.ArrayIndexOutOfBoundsException"],
> "msg":"java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds
> for length 2",
> The stacktrace is :
> org.apache.solr.common.SolrException:
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
> at org.apache.solr.search.ReRankCollector.topDocs(ReRankCollector.java:154)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:159
> 9)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1413
> )
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryC
> omponent.java:1513)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:403
> )
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.
> java:360)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java
> :214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:568)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
> a:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235
> )
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:161
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233
> )
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:130
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580
> )
> at
[GitHub] [lucene-solr] dsmiley commented on a change in pull request #2230: SOLR-15011: /admin/logging handler is configured logs to all nodes
dsmiley commented on a change in pull request #2230:
URL: https://github.com/apache/lucene-solr/pull/2230#discussion_r562635350
##
File path: solr/core/src/java/org/apache/solr/handler/admin/LoggingHandler.java
##
@@ -63,6 +65,9 @@ public void inform(SolrCore core) {
if (watcher == null) {
watcher = core.getCoreContainer().getLogging();
}
+if (cc == null) {
Review comment:
does this actually happen (how?). Otherwise, let's not and furthermore
declare cc as final.
##
File path: solr/core/src/java/org/apache/solr/handler/admin/LoggingHandler.java
##
@@ -151,6 +156,9 @@ public void handleRequestBody(SolrQueryRequest req,
SolrQueryResponse rsp) throw
rsp.add("loggers", info);
}
rsp.setHttpCaching(false);
+if (cc != null && AdminHandlersProxy.maybeProxyToNodes(req, rsp, cc)) {
Review comment:
Why do this at the end of this method instead of at the top (along with
disabling http caching)? By doing it at the end, if nodes=FOO yet the current
node is BAR, it would do work it shouldn't be doing; right? Notice where the
other callers of AdminHandlersProxy.maybeProxyToNodes put their logic.
##
File path: solr/webapp/web/js/angular/services.js
##
@@ -58,7 +58,7 @@ solrAdminServices.factory('System',
}])
.factory('Logging',
['$resource', function($resource) {
-return $resource('admin/info/logging', {'wt':'json', '_':Date.now()}, {
+return $resource('admin/info/logging', {'wt':'json', 'nodes': 'all',
'_':Date.now()}, {
Review comment:
I'm very unfamiliar with the admin UI code structure. Can you explain
why nodes=all needed to be set in two places?
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-15071) Bug on LTR when using solr 8.6.3 - index out of bounds DisiPriorityQueue.add(DisiPriorityQueue.java:102)
[
https://issues.apache.org/jira/browse/SOLR-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270163#comment-17270163
]
ASF subversion and git services commented on SOLR-15071:
Commit db95a292725c480b71e9ec8c05a54b60d32d55f6 in lucene-solr's branch
refs/heads/branch_8x from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=db95a29 ]
SOLR-15071: Fix ArrayIndexOutOfBoundsException in contrib/ltr SolrFeatureScorer
(#2196)
> Bug on LTR when using solr 8.6.3 - index out of bounds
> DisiPriorityQueue.add(DisiPriorityQueue.java:102)
>
>
> Key: SOLR-15071
> URL: https://issues.apache.org/jira/browse/SOLR-15071
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 8.6, 8.7
>Reporter: Florin Babes
>Assignee: Christine Poerschke
>Priority: Major
> Labels: ltr
> Fix For: 8.8
>
> Attachments: featurestore+model+sample_documents.zip
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hello,
> We are trying to update Solr from 8.3.1 to 8.6.3. On Solr 8.3.1 we are
> using LTR in production using a MultipleAdditiveTrees model. On Solr 8.6.3
> we receive an error when we try to compute some SolrFeatures. We didn't
> find any pattern of the queries that fail.
> Example:
> We have the following query raw parameters:
> q=lg cx 4k oled 120 hz -> just of many examples
> term_dq=lg cx 4k oled 120 hz
> rq={!ltr model=model reRankDocs=1000 store=feature_store
> efi.term=${term_dq}}
> defType=edismax,
> mm=2<75%
> The features are something like this:
> {
> "name":"similarity_query_fileld_1",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_1 mm=1}${term}"},
> "store":"feature_store"
> },
> {
> "name":"similarity_query_field_2",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_2 mm=5}${term}"},
> "store":"feature_store"
> }
> We are testing ~6300 production queries and for about 1% of them we receive
> that following error message:
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","java.lang.ArrayIndexOutOfBoundsException"],
> "msg":"java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds
> for length 2",
> The stacktrace is :
> org.apache.solr.common.SolrException:
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
> at org.apache.solr.search.ReRankCollector.topDocs(ReRankCollector.java:154)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:159
> 9)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1413
> )
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryC
> omponent.java:1513)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:403
> )
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.
> java:360)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java
> :214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:568)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
> a:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235
> )
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:161
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233
> )
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:130
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580
> )
>
[jira] [Commented] (SOLR-15071) Bug on LTR when using solr 8.6.3 - index out of bounds DisiPriorityQueue.add(DisiPriorityQueue.java:102)
[
https://issues.apache.org/jira/browse/SOLR-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270176#comment-17270176
]
ASF subversion and git services commented on SOLR-15071:
Commit 3046bcf608fb6bdd6fe8fcd5fd7213103e802c9d in lucene-solr's branch
refs/heads/branch_8_8 from Christine Poerschke
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=3046bcf ]
SOLR-15071: Fix ArrayIndexOutOfBoundsException in contrib/ltr SolrFeatureScorer
(#2196)
> Bug on LTR when using solr 8.6.3 - index out of bounds
> DisiPriorityQueue.add(DisiPriorityQueue.java:102)
>
>
> Key: SOLR-15071
> URL: https://issues.apache.org/jira/browse/SOLR-15071
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 8.6, 8.7
>Reporter: Florin Babes
>Assignee: Christine Poerschke
>Priority: Major
> Labels: ltr
> Fix For: 8.8
>
> Attachments: featurestore+model+sample_documents.zip
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hello,
> We are trying to update Solr from 8.3.1 to 8.6.3. On Solr 8.3.1 we are
> using LTR in production using a MultipleAdditiveTrees model. On Solr 8.6.3
> we receive an error when we try to compute some SolrFeatures. We didn't
> find any pattern of the queries that fail.
> Example:
> We have the following query raw parameters:
> q=lg cx 4k oled 120 hz -> just of many examples
> term_dq=lg cx 4k oled 120 hz
> rq={!ltr model=model reRankDocs=1000 store=feature_store
> efi.term=${term_dq}}
> defType=edismax,
> mm=2<75%
> The features are something like this:
> {
> "name":"similarity_query_fileld_1",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_1 mm=1}${term}"},
> "store":"feature_store"
> },
> {
> "name":"similarity_query_field_2",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_2 mm=5}${term}"},
> "store":"feature_store"
> }
> We are testing ~6300 production queries and for about 1% of them we receive
> that following error message:
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","java.lang.ArrayIndexOutOfBoundsException"],
> "msg":"java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds
> for length 2",
> The stacktrace is :
> org.apache.solr.common.SolrException:
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
> at org.apache.solr.search.ReRankCollector.topDocs(ReRankCollector.java:154)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:159
> 9)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1413
> )
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryC
> omponent.java:1513)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:403
> )
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.
> java:360)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java
> :214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:568)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
> a:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235
> )
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:161
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233
> )
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:130
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580
> )
[jira] [Commented] (SOLR-15071) Bug on LTR when using solr 8.6.3 - index out of bounds DisiPriorityQueue.add(DisiPriorityQueue.java:102)
[
https://issues.apache.org/jira/browse/SOLR-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270174#comment-17270174
]
ASF subversion and git services commented on SOLR-15071:
Commit e2e375c397701b6bd3d5c55f7e48bc3dc465f9ee in lucene-solr's branch
refs/heads/branch_8_8 from Florin Babes
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e2e375c ]
SOLR-15071: add TestEdisMaxSolrFeature.testEdisMaxSolrFeatureCustomMM() test
case (#2201)
* add test case for SOLR-15071
* add temporary @Ignore to be removed when the fix is committed
Co-authored-by: Florin Babes
Co-authored-by: Christine Poerschke
> Bug on LTR when using solr 8.6.3 - index out of bounds
> DisiPriorityQueue.add(DisiPriorityQueue.java:102)
>
>
> Key: SOLR-15071
> URL: https://issues.apache.org/jira/browse/SOLR-15071
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 8.6, 8.7
>Reporter: Florin Babes
>Assignee: Christine Poerschke
>Priority: Major
> Labels: ltr
> Fix For: 8.8
>
> Attachments: featurestore+model+sample_documents.zip
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hello,
> We are trying to update Solr from 8.3.1 to 8.6.3. On Solr 8.3.1 we are
> using LTR in production using a MultipleAdditiveTrees model. On Solr 8.6.3
> we receive an error when we try to compute some SolrFeatures. We didn't
> find any pattern of the queries that fail.
> Example:
> We have the following query raw parameters:
> q=lg cx 4k oled 120 hz -> just of many examples
> term_dq=lg cx 4k oled 120 hz
> rq={!ltr model=model reRankDocs=1000 store=feature_store
> efi.term=${term_dq}}
> defType=edismax,
> mm=2<75%
> The features are something like this:
> {
> "name":"similarity_query_fileld_1",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_1 mm=1}${term}"},
> "store":"feature_store"
> },
> {
> "name":"similarity_query_field_2",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_2 mm=5}${term}"},
> "store":"feature_store"
> }
> We are testing ~6300 production queries and for about 1% of them we receive
> that following error message:
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","java.lang.ArrayIndexOutOfBoundsException"],
> "msg":"java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds
> for length 2",
> The stacktrace is :
> org.apache.solr.common.SolrException:
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
> at org.apache.solr.search.ReRankCollector.topDocs(ReRankCollector.java:154)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:159
> 9)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1413
> )
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryC
> omponent.java:1513)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:403
> )
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.
> java:360)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java
> :214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:568)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
> a:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235
> )
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:161
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233
> )
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:130
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.ecli
[jira] [Commented] (SOLR-15071) Bug on LTR when using solr 8.6.3 - index out of bounds DisiPriorityQueue.add(DisiPriorityQueue.java:102)
[
https://issues.apache.org/jira/browse/SOLR-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270175#comment-17270175
]
ASF subversion and git services commented on SOLR-15071:
Commit e2e375c397701b6bd3d5c55f7e48bc3dc465f9ee in lucene-solr's branch
refs/heads/branch_8_8 from Florin Babes
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=e2e375c ]
SOLR-15071: add TestEdisMaxSolrFeature.testEdisMaxSolrFeatureCustomMM() test
case (#2201)
* add test case for SOLR-15071
* add temporary @Ignore to be removed when the fix is committed
Co-authored-by: Florin Babes
Co-authored-by: Christine Poerschke
> Bug on LTR when using solr 8.6.3 - index out of bounds
> DisiPriorityQueue.add(DisiPriorityQueue.java:102)
>
>
> Key: SOLR-15071
> URL: https://issues.apache.org/jira/browse/SOLR-15071
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 8.6, 8.7
>Reporter: Florin Babes
>Assignee: Christine Poerschke
>Priority: Major
> Labels: ltr
> Fix For: 8.8
>
> Attachments: featurestore+model+sample_documents.zip
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hello,
> We are trying to update Solr from 8.3.1 to 8.6.3. On Solr 8.3.1 we are
> using LTR in production using a MultipleAdditiveTrees model. On Solr 8.6.3
> we receive an error when we try to compute some SolrFeatures. We didn't
> find any pattern of the queries that fail.
> Example:
> We have the following query raw parameters:
> q=lg cx 4k oled 120 hz -> just of many examples
> term_dq=lg cx 4k oled 120 hz
> rq={!ltr model=model reRankDocs=1000 store=feature_store
> efi.term=${term_dq}}
> defType=edismax,
> mm=2<75%
> The features are something like this:
> {
> "name":"similarity_query_fileld_1",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_1 mm=1}${term}"},
> "store":"feature_store"
> },
> {
> "name":"similarity_query_field_2",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_2 mm=5}${term}"},
> "store":"feature_store"
> }
> We are testing ~6300 production queries and for about 1% of them we receive
> that following error message:
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","java.lang.ArrayIndexOutOfBoundsException"],
> "msg":"java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds
> for length 2",
> The stacktrace is :
> org.apache.solr.common.SolrException:
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
> at org.apache.solr.search.ReRankCollector.topDocs(ReRankCollector.java:154)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:159
> 9)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1413
> )
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryC
> omponent.java:1513)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:403
> )
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.
> java:360)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java
> :214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:568)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
> a:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235
> )
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:161
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233
> )
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:130
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.ecli
[jira] [Commented] (SOLR-15071) Bug on LTR when using solr 8.6.3 - index out of bounds DisiPriorityQueue.add(DisiPriorityQueue.java:102)
[
https://issues.apache.org/jira/browse/SOLR-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270197#comment-17270197
]
Christine Poerschke commented on SOLR-15071:
Thanks [~dsmiley] for the PR reviews!
As per above the changes have been committed to master, branch_8x and
branch_8_8 branches.
I'll keep this ticket open until it's known if the fix will be included in
8.8.0 or not. If not then the CHANGES.txt entry will need to be moved out of
the 8.8.0 section and the "Fix Version" attributes of the JIRA be updated here.
> Bug on LTR when using solr 8.6.3 - index out of bounds
> DisiPriorityQueue.add(DisiPriorityQueue.java:102)
>
>
> Key: SOLR-15071
> URL: https://issues.apache.org/jira/browse/SOLR-15071
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 8.6, 8.7
>Reporter: Florin Babes
>Assignee: Christine Poerschke
>Priority: Major
> Labels: ltr
> Fix For: 8.8
>
> Attachments: featurestore+model+sample_documents.zip
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hello,
> We are trying to update Solr from 8.3.1 to 8.6.3. On Solr 8.3.1 we are
> using LTR in production using a MultipleAdditiveTrees model. On Solr 8.6.3
> we receive an error when we try to compute some SolrFeatures. We didn't
> find any pattern of the queries that fail.
> Example:
> We have the following query raw parameters:
> q=lg cx 4k oled 120 hz -> just of many examples
> term_dq=lg cx 4k oled 120 hz
> rq={!ltr model=model reRankDocs=1000 store=feature_store
> efi.term=${term_dq}}
> defType=edismax,
> mm=2<75%
> The features are something like this:
> {
> "name":"similarity_query_fileld_1",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_1 mm=1}${term}"},
> "store":"feature_store"
> },
> {
> "name":"similarity_query_field_2",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_2 mm=5}${term}"},
> "store":"feature_store"
> }
> We are testing ~6300 production queries and for about 1% of them we receive
> that following error message:
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","java.lang.ArrayIndexOutOfBoundsException"],
> "msg":"java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds
> for length 2",
> The stacktrace is :
> org.apache.solr.common.SolrException:
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
> at org.apache.solr.search.ReRankCollector.topDocs(ReRankCollector.java:154)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:159
> 9)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1413
> )
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryC
> omponent.java:1513)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:403
> )
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.
> java:360)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java
> :214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:568)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
> a:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235
> )
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:161
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233
> )
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:130
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.serv
[jira] [Updated] (SOLR-15071) Bug on LTR when using solr 8.6.3 - index out of bounds DisiPriorityQueue.add(DisiPriorityQueue.java:102)
[
https://issues.apache.org/jira/browse/SOLR-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christine Poerschke updated SOLR-15071:
---
Fix Version/s: master (9.0)
> Bug on LTR when using solr 8.6.3 - index out of bounds
> DisiPriorityQueue.add(DisiPriorityQueue.java:102)
>
>
> Key: SOLR-15071
> URL: https://issues.apache.org/jira/browse/SOLR-15071
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: contrib - LTR
>Affects Versions: 8.6, 8.7
>Reporter: Florin Babes
>Assignee: Christine Poerschke
>Priority: Major
> Labels: ltr
> Fix For: 8.8, master (9.0)
>
> Attachments: featurestore+model+sample_documents.zip
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Hello,
> We are trying to update Solr from 8.3.1 to 8.6.3. On Solr 8.3.1 we are
> using LTR in production using a MultipleAdditiveTrees model. On Solr 8.6.3
> we receive an error when we try to compute some SolrFeatures. We didn't
> find any pattern of the queries that fail.
> Example:
> We have the following query raw parameters:
> q=lg cx 4k oled 120 hz -> just of many examples
> term_dq=lg cx 4k oled 120 hz
> rq={!ltr model=model reRankDocs=1000 store=feature_store
> efi.term=${term_dq}}
> defType=edismax,
> mm=2<75%
> The features are something like this:
> {
> "name":"similarity_query_fileld_1",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_1 mm=1}${term}"},
> "store":"feature_store"
> },
> {
> "name":"similarity_query_field_2",
> "class":"org.apache.solr.ltr.feature.SolrFeature",
> "params":\{"q":"{!dismax qf=query_field_2 mm=5}${term}"},
> "store":"feature_store"
> }
> We are testing ~6300 production queries and for about 1% of them we receive
> that following error message:
> "metadata":[
> "error-class","org.apache.solr.common.SolrException",
> "root-error-class","java.lang.ArrayIndexOutOfBoundsException"],
> "msg":"java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds
> for length 2",
> The stacktrace is :
> org.apache.solr.common.SolrException:
> java.lang.ArrayIndexOutOfBoundsException: Index 2 out of bounds for length 2
> at org.apache.solr.search.ReRankCollector.topDocs(ReRankCollector.java:154)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:159
> 9)
> at
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1413
> )
> at
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
> at
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryC
> omponent.java:1513)
> at
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:403
> )
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.
> java:360)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java
> :214)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:2627)
> at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:795)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:568)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:415)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:345)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.jav
> a:1596)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:545)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:590)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235
> )
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:161
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233
> )
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:130
> 0)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:485)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1580
> )
> at
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1215
> )
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHand
[GitHub] [lucene-solr-operator] thelabdude opened a new pull request #195: Improve Prom exporter docs
thelabdude opened a new pull request #195: URL: https://github.com/apache/lucene-solr-operator/pull/195 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-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270211#comment-17270211
]
ASF subversion and git services commented on SOLR-13105:
Commit ac29470d99b77e7c4e0a1bd11f09e4c951f426c0 in lucene-solr's branch
refs/heads/branch_8_8 from Cassandra Targett
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=ac29470 ]
SOLR-13105 - Visual Guide to Math Expressions (#2227)
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
This message was sent by Atlassian Jira
(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-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270212#comment-17270212
]
Cassandra Targett commented on SOLR-13105:
--
All right, since it will be a few more days for the next vote, I backported
this into 8.8. Yeay!
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
This message was sent by Atlassian Jira
(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-13105) A visual guide to Solr Math Expressions and Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-13105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cassandra Targett resolved SOLR-13105.
--
Fix Version/s: 8.8
Resolution: Fixed
> A visual guide to Solr Math Expressions and Streaming Expressions
> -
>
> Key: SOLR-13105
> URL: https://issues.apache.org/jira/browse/SOLR-13105
> Project: Solr
> Issue Type: New Feature
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Fix For: 8.8
>
> Attachments: Screen Shot 2019-01-14 at 10.56.32 AM.png, Screen Shot
> 2019-02-21 at 2.14.43 PM.png, Screen Shot 2019-03-03 at 2.28.35 PM.png,
> Screen Shot 2019-03-04 at 7.47.57 PM.png, Screen Shot 2019-03-13 at 10.47.47
> AM.png, Screen Shot 2019-03-30 at 6.17.04 PM.png
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Visualization is now a fundamental element of Solr Streaming Expressions and
> Math Expressions. This ticket will create a visual guide to Solr Math
> Expressions and Solr Streaming Expressions that includes *Apache Zeppelin*
> visualization examples.
> It will also cover using the JDBC expression to *analyze* and *visualize*
> results from any JDBC compliant data source.
> Intro from the guide:
> {code:java}
> Streaming Expressions exposes the capabilities of Solr Cloud as composable
> functions. These functions provide a system for searching, transforming,
> analyzing and visualizing data stored in Solr Cloud collections.
> At a high level there are four main capabilities that will be explored in the
> documentation:
> * Searching, sampling and aggregating results from Solr.
> * Transforming result sets after they are retrieved from Solr.
> * Analyzing and modeling result sets using probability and statistics and
> machine learning libraries.
> * Visualizing result sets, aggregations and statistical models of the data.
> {code}
>
> A few sample visualizations are attached to the ticket.
--
This message was sent by Atlassian Jira
(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-operator] thelabdude opened a new issue #196: TestMetricsReconcileWithUserProvidedConfig is flaky in CI
thelabdude opened a new issue #196:
URL: https://github.com/apache/lucene-solr-operator/issues/196
From my PR https://github.com/apache/lucene-solr-operator/pull/195 which
shouldn't have any impact on tests:
```
2021-01-22T15:26:12.8765061Z --- FAIL:
TestMetricsReconcileWithUserProvidedConfig (1.36s)
2021-01-22T15:26:12.8765624Z controller_utils_test.go:210:
2021-01-22T15:26:12.8766009Z Error Trace:
controller_utils_test.go:210
2021-01-22T15:26:12.8766448Z
solrprometheusexporter_controller_test.go:666
2021-01-22T15:26:12.8766837Z Error: Not equal:
2021-01-22T15:26:12.8767344Z expected:
map[string]string{"solr.apache.org/exporterConfigXmlMd5":"8703af5bf925eceae3feda704cfa8411"}
2021-01-22T15:26:12.8768149Z actual :
map[string]string{"solr.apache.org/exporterConfigXmlMd5":"7fbc8424eab044dca4a00dad7b3819dd"}
2021-01-22T15:26:12.8768609Z
2021-01-22T15:26:12.8768879Z Diff:
2021-01-22T15:26:12.8769416Z --- Expected
2021-01-22T15:26:12.8769705Z +++ Actual
2021-01-22T15:26:12.8770155Z @@ -1,3 +1,3 @@
2021-01-22T15:26:12.8770479Z
(map[string]string) (len=1) {
2021-01-22T15:26:12.8771394Z - (string)
(len=36) "solr.apache.org/exporterConfigXmlMd5": (string) (len=32)
"8703af5bf925eceae3feda704cfa8411"
2021-01-22T15:26:12.8772071Z + (string)
(len=36) "solr.apache.org/exporterConfigXmlMd5": (string) (len=32)
"7fbc8424eab044dca4a00dad7b3819dd"
2021-01-22T15:26:12.8772545Z }
2021-01-22T15:26:12.8772962Z Test:
TestMetricsReconcileWithUserProvidedConfig
2021-01-22T15:26:12.8773492Z Messages: Expected and
found pod annotations are not the same
2021-01-22T15:26:12.8773829Z FAIL
2021-01-22T15:26:12.8774152Z coverage: 52.8% of statements
2021-01-22T15:26:12.8774763Z FAIL
github.com/apache/lucene-solr-operator/controllers 30.823s
2021-01-22T15:26:12.8775505Z ok
github.com/apache/lucene-solr-operator/controllers/util 0.018s coverage: 10.7%
of statements
2021-01-22T15:26:12.8776272Z ?
github.com/apache/lucene-solr-operator/controllers/util/solr_api[no
test files]
2021-01-22T15:26:12.8776653Z FAIL
2021-01-22T15:26:12.8776976Z make: *** [test] Error 1
2021-01-22T15:26:12.8777461Z Makefile:52: recipe for target 'test' failed
2021-01-22T15:26:12.8780171Z ##[error]Process completed with exit code 2.
```
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-10203) Remove dist/test-framework from the binary download archive
[ https://issues.apache.org/jira/browse/SOLR-10203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270238#comment-17270238 ] Atri Sharma commented on SOLR-10203: Not that I know of – but IIUC a project needs to pull its own dependencies automatically and ensure that all dependencies are correctly licensed > Remove dist/test-framework from the binary download archive > --- > > Key: SOLR-10203 > URL: https://issues.apache.org/jira/browse/SOLR-10203 > Project: Solr > Issue Type: Sub-task > Components: Build >Affects Versions: 7.0 >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Minor > > Libraries in the dist/test-framework are shipped with every copy of Solr > binary, yet they are not used anywhere directly. They take approximately 10 > MBytes. > Remove the directory and provide guidance in a README file on how to get them > for those people who are writing their own testing solutions against Solr. -- 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-15101) Add list-backups and delete-backups APIs
Jason Gerlowski created SOLR-15101: -- Summary: Add list-backups and delete-backups APIs Key: SOLR-15101 URL: https://issues.apache.org/jira/browse/SOLR-15101 Project: Solr Issue Type: Sub-task Security Level: Public (Default Security Level. Issues are Public) Affects Versions: master (9.0) Reporter: Jason Gerlowski Assignee: Jason Gerlowski The accepted SIP-12 outlines a plan for changing Solr's backup file structure in a way that supports storing multiple backups within a single "location" URI. With this comes a need for APIs that can list out and delete backups within that single location. SIP-12 has v1 and v2 API specs for these APIs. This ticket covers implementing them. -- 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-15101) Add list-backups and delete-backups APIs
[ https://issues.apache.org/jira/browse/SOLR-15101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270248#comment-17270248 ] Jason Gerlowski commented on SOLR-15101: One detail that didn't come up during SIP-12 discussion was how these APIs should respond when pointed at a backup location using the old (non-incremental) file layout. "Listing" and "deleting" carry implications (i.e. multiple backups per location) that aren't possible in the old file structure. What would it mean to list the backups, or delete backupId=5 at a particular location that can only ever have 0 or 1 backups? For that reason I'm leaning towards having the APIs return a 400 or some other appropriate error if used on an old backup location. > Add list-backups and delete-backups APIs > > > Key: SOLR-15101 > URL: https://issues.apache.org/jira/browse/SOLR-15101 > Project: Solr > Issue Type: Sub-task > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Jason Gerlowski >Assignee: Jason Gerlowski >Priority: Major > > The accepted SIP-12 outlines a plan for changing Solr's backup file structure > in a way that supports storing multiple backups within a single "location" > URI. With this comes a need for APIs that can list out and delete backups > within that single location. > SIP-12 has v1 and v2 API specs for these APIs. This ticket covers > implementing them. -- 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-operator] thelabdude opened a new pull request #197: Wait for another reconcile request to fix flaky test in CI
thelabdude opened a new pull request #197: URL: https://github.com/apache/lucene-solr-operator/pull/197 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-operator] HoustonPutman commented on a change in pull request #197: Wait for another reconcile request to fix flaky test in CI
HoustonPutman commented on a change in pull request #197:
URL:
https://github.com/apache/lucene-solr-operator/pull/197#discussion_r562752902
##
File path: controllers/solrprometheusexporter_controller_test.go
##
@@ -656,10 +657,14 @@ func TestMetricsReconcileWithUserProvidedConfig(t
*testing.T) {
updatedConfigXml := "updated by user"
updateUserProvidedConfigMap(testClient, g, userProvidedConfigMapNN,
map[string]string{util.PrometheusExporterConfigMapKey: updatedConfigXml})
- // reconcile should happen again
+ // reconcile should happen again 2x
g.Eventually(requests,
timeout).Should(gomega.Receive(gomega.Equal(expectedMetricsRequest)))
+ g.Eventually(requests,
timeout).Should(gomega.Receive(gomega.Equal(expectedMetricsRequest)))
+
Review comment:
In the [solrxml
test](https://github.com/apache/lucene-solr-operator/blob/main/controllers/solrcloud_controller_test.go#L772),
we added a 250 ms sleep to make sure it passed consistently. Might make sense
to have here as well.
##
File path: controllers/solrprometheusexporter_controller_test.go
##
@@ -656,10 +657,14 @@ func TestMetricsReconcileWithUserProvidedConfig(t
*testing.T) {
updatedConfigXml := "updated by user"
updateUserProvidedConfigMap(testClient, g, userProvidedConfigMapNN,
map[string]string{util.PrometheusExporterConfigMapKey: updatedConfigXml})
- // reconcile should happen again
+ // reconcile should happen again 2x
g.Eventually(requests,
timeout).Should(gomega.Receive(gomega.Equal(expectedMetricsRequest)))
+ g.Eventually(requests,
timeout).Should(gomega.Receive(gomega.Equal(expectedMetricsRequest)))
+
+ deployment = &appsv1.Deployment{}
+ err = testClient.Get(context.TODO(), metricsDKey, deployment)
+ g.Expect(err).NotTo(gomega.HaveOccurred())
- deployment = expectDeployment(t, g, requests, expectedMetricsRequest,
metricsDKey, userProvidedConfigMap.Name)
Review comment:
Was `expectDeployment` not giving you the updated deployment?
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-operator] thelabdude commented on a change in pull request #197: Wait for another reconcile request to fix flaky test in CI
thelabdude commented on a change in pull request #197:
URL:
https://github.com/apache/lucene-solr-operator/pull/197#discussion_r562762422
##
File path: controllers/solrprometheusexporter_controller_test.go
##
@@ -656,10 +657,14 @@ func TestMetricsReconcileWithUserProvidedConfig(t
*testing.T) {
updatedConfigXml := "updated by user"
updateUserProvidedConfigMap(testClient, g, userProvidedConfigMapNN,
map[string]string{util.PrometheusExporterConfigMapKey: updatedConfigXml})
- // reconcile should happen again
+ // reconcile should happen again 2x
g.Eventually(requests,
timeout).Should(gomega.Receive(gomega.Equal(expectedMetricsRequest)))
+ g.Eventually(requests,
timeout).Should(gomega.Receive(gomega.Equal(expectedMetricsRequest)))
+
+ deployment = &appsv1.Deployment{}
+ err = testClient.Get(context.TODO(), metricsDKey, deployment)
+ g.Expect(err).NotTo(gomega.HaveOccurred())
- deployment = expectDeployment(t, g, requests, expectedMetricsRequest,
metricsDKey, userProvidedConfigMap.Name)
Review comment:
that was me just trying to simplify test logic but I changed it back
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-operator] sepulworld opened a new issue #198: Integration tests via Github Actions and Minikube
sepulworld opened a new issue #198: URL: https://github.com/apache/lucene-solr-operator/issues/198 I believe it might be quiet useful to do some integration tests on the supported version of K8s and SolrCloud (aka, SolrCluster) after unit tests are run. Looks like Github Actions supports Minikube well enough now to explore this. https://minikube.sigs.k8s.io/docs/tutorials/setup_minikube_in_github_actions/ Any thoughts on this? I can put some time into a framework and do some initial tests for a proof of concept if there is interest. 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-15096) [REGRESSION] Collection Delete Performance significantly degraded in 9.0 v 8.8
[
https://issues.apache.org/jira/browse/SOLR-15096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270297#comment-17270297
]
Mike Drob commented on SOLR-15096:
--
I suspected it might be a Zookeeper version issue, but we are using 3.6.2 in
both places so that's not it.
> [REGRESSION] Collection Delete Performance significantly degraded in 9.0 v 8.8
> --
>
> Key: SOLR-15096
> URL: https://issues.apache.org/jira/browse/SOLR-15096
> Project: Solr
> Issue Type: Bug
>Affects Versions: master (9.0)
>Reporter: Mike Drob
>Priority: Blocker
> Fix For: master (9.0)
>
> Attachments: Screen Shot 2021-01-21 at 5.44.25 PM.png
>
>
> While doing some other performance testing I noticed that collection deletion
> in 8.8 (RC1) would take approximately 200ms, while the same operation would
> take 800ms using a recent snapshot ({{a233ed2fd1b}}) from master branch.
> I have not done further investigation at this time.
--
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-14608) Faster sorting for the /export handler
[ https://issues.apache.org/jira/browse/SOLR-14608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270300#comment-17270300 ] Gus Heck commented on SOLR-14608: - Came back to re-read this to fuel a better understanding of sort memory requirements after an OOM on a relatively simple query that should yield ~38k docs out of an 11 Billion doc corpus (but other stuff including data ingestion was going on, so it's not a clean case, just a bit of a surprise since I assumed that the sort memory would relate to the 38k docs, which seemed like it ought to be trivial, only a few fields were requested all numeric or short strings, probably ~0.25k/doc so maybe 8 Mb?). Did you ever investigate my prior question regarding queue size? And I'm also wondering if your algorithm is dependent on having a lot of segments, what if there's been a force-merge? Above in your description of the current algorithm you say "turn off the bits in the bit set" I'm assuming this means just the bits for the docs that were "sent"? and when you say "sent" you mean sent to the coordinating node? > Faster sorting for the /export handler > -- > > Key: SOLR-14608 > URL: https://issues.apache.org/jira/browse/SOLR-14608 > Project: Solr > Issue Type: New Feature >Affects Versions: master (9.0) >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Major > Fix For: master (9.0) > > > The largest cost of the export handler is the sorting. This ticket will > implement an improved algorithm for sorting that should greatly increase > overall throughput for the export handler. > *The current algorithm is as follows:* > Collect a bitset of matching docs. Iterate over that bitset and materialize > the top level oridinals for the sort fields in the document and add them to > priority queue of size 3. Then export the top 3 docs, turn off the > bits in the bit set and iterate again until all docs are sorted and sent. > There are two performance bottlenecks with this approach: > 1) Materializing the top level ordinals adds a huge amount of overhead to the > sorting process. > 2) The size of priority queue, 30,000, adds significant overhead to sorting > operations. > *The new algorithm:* > Has a top level *merge sort iterator* that wraps segment level iterators that > perform segment level priority queue sorts. > *Segment level:* > The segment level docset will be iterated and the segment level ordinals for > the sort fields will be materialized and added to a segment level priority > queue. As the segment level iterator pops docs from the priority queue the > top level ordinals for the sort fields are materialized. Because the top > level ordinals are materialized AFTER the sort, they only need to be looked > up when the segment level ordinal changes. This takes advantage of the sort > to limit the lookups into the top level ordinal structures. This also > eliminates redundant lookups of top level ordinals that occur during the > multiple passes over the matching docset. > The segment level priority queues can be kept smaller than 30,000 to improve > performance of the sorting operations because the overall batch size will > still be 30,000 or greater when all the segment priority queue sizes are > added up. This allows for batch sizes much larger then 30,000 without using a > single large priority queue. The increased batch size means fewer iterations > over the matching docset and the decreased priority queue size means faster > sorting operations. > *Top level:* > A top level iterator does a merge sort over the segment level iterators by > comparing the top level ordinals materialized when the segment level docs are > popped from the segment level priority queues. This requires no extra memory > and will be very performant. > -- 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-operator] thelabdude merged pull request #197: Wait for another reconcile request to fix flaky test in CI
thelabdude merged pull request #197: URL: https://github.com/apache/lucene-solr-operator/pull/197 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-operator] thelabdude closed issue #196: TestMetricsReconcileWithUserProvidedConfig is flaky in CI
thelabdude closed issue #196: URL: https://github.com/apache/lucene-solr-operator/issues/196 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] msokolov commented on a change in pull request #2220: LUCENE-8626: Lucene standardize tests part 3 and final
msokolov commented on a change in pull request #2220:
URL: https://github.com/apache/lucene-solr/pull/2220#discussion_r562792732
##
File path:
lucene/queryparser/src/test/org/apache/lucene/queryparser/surround/query/Test02Boolean.java
##
@@ -46,11 +46,11 @@ public void setUp() throws Exception {
SingleFieldTestDb db1;
public void normalTest1(String query, int[] expdnrs) throws Exception {
-BooleanQueryTst bqt =
-new BooleanQueryTst(
+TestBooleanQuery tbq =
Review comment:
ooh fancy
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] msokolov merged pull request #2220: LUCENE-8626: Lucene standardize tests part 3 and final
msokolov merged pull request #2220: URL: https://github.com/apache/lucene-solr/pull/2220 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-8626) standardise test class naming
[ https://issues.apache.org/jira/browse/LUCENE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270317#comment-17270317 ] ASF subversion and git services commented on LUCENE-8626: - Commit 4bc5d51494c0c0441d58b0e030da8f843d9b9897 in lucene-solr's branch refs/heads/master from Marcus [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4bc5d51 ] LUCENE-8626: Lucene standardize test naming part 3 and final (#2220) > standardise test class naming > - > > Key: LUCENE-8626 > URL: https://issues.apache.org/jira/browse/LUCENE-8626 > Project: Lucene - Core > Issue Type: Test >Reporter: Christine Poerschke >Priority: Major > Attachments: SOLR-12939.01.patch, SOLR-12939.02.patch, > SOLR-12939.03.patch, SOLR-12939_hoss_validation_groovy_experiment.patch > > Time Spent: 4h > Remaining Estimate: 0h > > This was mentioned and proposed on the dev mailing list. Starting this ticket > here to start to make it happen? > History: This ticket was created as > https://issues.apache.org/jira/browse/SOLR-12939 ticket and then got > JIRA-moved to become https://issues.apache.org/jira/browse/LUCENE-8626 ticket. -- 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-10203) Remove dist/test-framework from the binary download archive
[ https://issues.apache.org/jira/browse/SOLR-10203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270320#comment-17270320 ] David Eric Pugh commented on SOLR-10203: So... Does this mean that this ticket is potentially done? We don't have docs aroudn writing your own tests against solr in the ref guide. Maybe we just have a short page about it on the ref guide, so folks know it's possible... That sounds like a sperate issue however, and that we could close this one as done? > Remove dist/test-framework from the binary download archive > --- > > Key: SOLR-10203 > URL: https://issues.apache.org/jira/browse/SOLR-10203 > Project: Solr > Issue Type: Sub-task > Components: Build >Affects Versions: 7.0 >Reporter: Alexandre Rafalovitch >Assignee: Alexandre Rafalovitch >Priority: Minor > > Libraries in the dist/test-framework are shipped with every copy of Solr > binary, yet they are not used anywhere directly. They take approximately 10 > MBytes. > Remove the directory and provide guidance in a README file on how to get them > for those people who are writing their own testing solutions against Solr. -- 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-operator] thelabdude commented on pull request #151: Integrate with cert-manager to issue TLS certs for Solr
thelabdude commented on pull request #151: URL: https://github.com/apache/lucene-solr-operator/pull/151#issuecomment-765582655 I believe this code is ready but need to migrate the PR description to docs before we merge. 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-15073) Unsafe cast in SystemInfoHandler
[ https://issues.apache.org/jira/browse/SOLR-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270329#comment-17270329 ] ASF subversion and git services commented on SOLR-15073: Commit 64d445bbaab2a81dc57cde0394681970709b2251 in lucene-solr's branch refs/heads/master from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=64d445b ] Revert "SOLR-15073: Fix ClassCastException in SystemInfoHandler.getSecurityInfo (#2210)" This reverts commit fb88b0268aa0c7f14d77ae425b4851a8bedd2327. Resolved Conflicts: solr/CHANGES.txt > Unsafe cast in SystemInfoHandler > > > Key: SOLR-15073 > URL: https://issues.apache.org/jira/browse/SOLR-15073 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6, 8.7 >Reporter: Nikolay Ivanov >Assignee: Christine Poerschke >Priority: Major > Fix For: 8.8, master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have observed an unsafe cast in > SystemInfoHandler::getSecurityInfo > Is this by design? Currently I have a custom AuthorizationPlugin that > directly implements AuthorizationPlugin interface. With the latest solr > version it is not permitted anymore. A workaround is to extend the > RuleBasedAuthorizationPluginBase, which is not ideal imo. Please share your > thoughts -- 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-15073) Unsafe cast in SystemInfoHandler
[ https://issues.apache.org/jira/browse/SOLR-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270331#comment-17270331 ] ASF subversion and git services commented on SOLR-15073: Commit f78e23b4b82d597f228be0c02ffae59ca48079ac in lucene-solr's branch refs/heads/branch_8x from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f78e23b ] Revert "SOLR-15073: Fix ClassCastException in SystemInfoHandler.getSecurityInfo (#2210)" This reverts commit ec4917c45eaf7dccdcc98fba08484eb24e1ff5f2. Resolved Conflicts: solr/CHANGES.txt > Unsafe cast in SystemInfoHandler > > > Key: SOLR-15073 > URL: https://issues.apache.org/jira/browse/SOLR-15073 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6, 8.7 >Reporter: Nikolay Ivanov >Assignee: Christine Poerschke >Priority: Major > Fix For: 8.8, master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have observed an unsafe cast in > SystemInfoHandler::getSecurityInfo > Is this by design? Currently I have a custom AuthorizationPlugin that > directly implements AuthorizationPlugin interface. With the latest solr > version it is not permitted anymore. A workaround is to extend the > RuleBasedAuthorizationPluginBase, which is not ideal imo. Please share your > thoughts -- 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-15073) Unsafe cast in SystemInfoHandler
[ https://issues.apache.org/jira/browse/SOLR-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270334#comment-17270334 ] ASF subversion and git services commented on SOLR-15073: Commit 1d80911d529fcb31ee32ece6baa7585e60e39244 in lucene-solr's branch refs/heads/branch_8_8 from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1d80911 ] Revert "SOLR-15073: Fix ClassCastException in SystemInfoHandler.getSecurityInfo (#2210)" This reverts commit 07d5a6e8b7211858253ca7b7ba840126f0ef07d6. Resolved Conflicts: solr/CHANGES.txt > Unsafe cast in SystemInfoHandler > > > Key: SOLR-15073 > URL: https://issues.apache.org/jira/browse/SOLR-15073 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6, 8.7 >Reporter: Nikolay Ivanov >Assignee: Christine Poerschke >Priority: Major > Fix For: 8.8, master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have observed an unsafe cast in > SystemInfoHandler::getSecurityInfo > Is this by design? Currently I have a custom AuthorizationPlugin that > directly implements AuthorizationPlugin interface. With the latest solr > version it is not permitted anymore. A workaround is to extend the > RuleBasedAuthorizationPluginBase, which is not ideal imo. Please share your > thoughts -- 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-operator] HoustonPutman commented on a change in pull request #195: Improve Prom exporter docs
HoustonPutman commented on a change in pull request #195:
URL:
https://github.com/apache/lucene-solr-operator/pull/195#discussion_r562818271
##
File path: docs/solr-prometheus-exporter/README.md
##
@@ -49,4 +49,188 @@ All ACL fields are **required** if an ACL is used.
The Prometheus Exporter can be setup to scrape a standalone Solr instance.
In order to use this functionality, use the following spec field:
-`SolrPrometheusExporter.spec.solrRef.standalone.address`
\ No newline at end of file
+`SolrPrometheusExporter.spec.solrRef.standalone.address`
+
+## Prometheus Stack
+
+In this section, we'll walk through how to use the Prometheus exporter with
the [Prometheus
Stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack).
+
+The Prometheus Stack provides all the services you need for monitoring
Kubernetes applications like Solr and is the recommended way of deploying
Prometheus and Grafana.
+
+### Install Prometheus Stack
+
+Begin by installing the Prometheus Stack in the `monitoring` namespace with
Helm release name `mon`:
+```
+MONITOR_NS=monitoring
+PROM_OPER_REL=mon
+
+kubectl create ns ${MONITOR_NS}
+
+# see:
https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack
+if ! helm repo list | grep -q
"https://prometheus-community.github.io/helm-charts";; then
+ echo -e "\nAdding the prometheus-community repo to helm"
+ helm repo add prometheus-community
https://prometheus-community.github.io/helm-charts
+ helm repo add stable https://charts.helm.sh/stable
+ helm repo update
+fi
+
+helm upgrade --install ${PROM_OPER_REL}
prometheus-community/kube-prometheus-stack \
+--namespace ${MONITOR_NS} \
+--set kubeStateMetrics.enabled=false \
+--set nodeExporter.enabled=false
+```
+_Refer to the Prometheus stack documentation for detailed instructions._
+
+Verify you have Prometheus / Grafana pods running in the `monitoring`
namespace:
+```
+kubectl get pods -n monitoring
+```
+
+### Deploy Prometheus Exporter for Solr Metrics
+
+Next, deploy a Solr Prometheus exporter for the SolrCloud you want to capture
metrics from in the namespace where you're running SolrCloud, not in the
`monitoring` namespace.
+For instance, the following example creates a Prometheus exporter named
`dev-prom-exporter` for a SolrCloud named `dev` deployed in the `dev` namespace:
+```
+apiVersion: solr.apache.org/v1beta1
+kind: SolrPrometheusExporter
+metadata:
+ name: dev-prom-exporter
+spec:
+ customKubeOptions:
+podOptions:
+ resources:
+requests:
+ cpu: 300m
+ memory: 900Mi
+ solrReference:
+cloud:
+ name: "dev"
+ numThreads: 6
+```
+
+Look at the logs for your exporter pod to ensure it is running properly
(notice we're using a label filter vs. addressing the pod by name):
+```
+kubectl logs -l solr-prometheus-exporter=dev-prom-exporter
+```
+You should see some log messages that look similar to:
+```
+INFO - ;
org.apache.solr.prometheus.collector.SchedulerMetricsCollector; Beginning
metrics collection
+INFO - ;
org.apache.solr.prometheus.collector.SchedulerMetricsCollector; Completed
metrics collection
+```
+
+You can also see the metrics that are exported by the pod by opening a
port-forward to the exporter pod and hitting port 8080 with cURL:
+```
+kubectl port-forward $(kubectl get pod -l
solr-prometheus-exporter=dev-prom-exporter --no-headers -o
custom-columns=":metadata.name") 8080
+
+curl http://localhost:8080/metrics
+```
+ Customize Prometheus Exporter Config
+
+Each Solr pod exposes metrics as JSON from the `/solr/admin/metrics` endpoint.
To see this in action, open a port-forward to a Solr pod and send a request to
`http://localhost:8983/solr/admin/metrics`.
+
+The Prometheus exporter requests metrics from each pod and then extracts the
desired metrics using a series of [jq](https://stedolan.github.io/jq/) queries
against the JSON returned by each pod.
+
+By default, the Solr operator configures the exporter to use the config from
`/opt/solr/contrib/prometheus-exporter/conf/solr-exporter-config.xml`.
+
+If you need to customize the metrics exposed to Prometheus, you'll need to
provide a custom config XML via a ConfigMap and then configure the exporter CRD
to point to it.
+
+For instance, let's imagine you need to expose a new metric to Prometheus.
Start by pulling the default config from the exporter pod using:
+```
+EXPORTER_POD_ID=$(kubectl get pod -l
solr-prometheus-exporter=dev-prom-exporter --no-headers -o
custom-columns=":metadata.name"`)
+
+kubectl cp
$EXPORTER_POD_ID:/opt/solr/contrib/prometheus-exporter/conf/solr-exporter-config.xml
./solr-exporter-config.xml
+```
+Create a ConfigMap with your customized XML config under the
`solr-prometheus-exporter.xml` key.
+```
+apiVersion: v1
+data:
+ solr-prometheus-exporter.xml: |
+
+
+... YOUR CUSTOM CONFIG HERE ...
+
+kind: ConfigMap
+metadata:
+ name: custom-exporter-xml
[jira] [Commented] (SOLR-15073) Unsafe cast in SystemInfoHandler
[
https://issues.apache.org/jira/browse/SOLR-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270343#comment-17270343
]
Christine Poerschke commented on SOLR-15073:
All three branches' commits reverted, due to strange CI failures for 8x (but
not master it seems) with {{SolrInfoBeanTest}} 'complaining' about
{{org.apache.solr.handler.admin.SystemInfoHandlerTest$1}} i.e. possibly it's a
test issue somehow perhaps related to Mockito use and/or
{{SystemInfoHandlerTest.testMagickGetter()}} logic?
e.g. [https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.x/1438/]
extract
{code:java}
[junit4] 2> 508767 WARN
(TEST-SolrInfoBeanTest.testCallMBeanInfo-seed#[41C64ABFFDD9EACD]) [ ]
o.a.s.m.r.j.JmxMetricsReporter Unable to register gauge
[junit4] 2> => javax.management.NotCompliantMBeanException: Bad
getMBeanInfo()
[junit4] 2>at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getNewMBeanClassName(DefaultMBeanServerInterceptor.java:336)
[junit4] 2> javax.management.NotCompliantMBeanException: Bad getMBeanInfo()
[junit4] 2>at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getNewMBeanClassName(DefaultMBeanServerInterceptor.java:336)
~[?:?]
[junit4] 2>at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:319)
~[?:?]
[junit4] 2>at
com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
~[?:?]
[junit4] 2>at
org.apache.solr.metrics.reporters.jmx.JmxMetricsReporter$JmxListener.registerMBean(JmxMetricsReporter.java:536)
~[java/:?]
[junit4] 2>at
org.apache.solr.metrics.reporters.jmx.JmxMetricsReporter$JmxListener.onGaugeAdded(JmxMetricsReporter.java:574)
[java/:?]
[junit4] 2>at
com.codahale.metrics.MetricRegistry.notifyListenerOfAddedMetric(MetricRegistry.java:527)
[metrics-core-4.1.5.jar:4.1.5]
[junit4] 2>at
com.codahale.metrics.MetricRegistry.onMetricAdded(MetricRegistry.java:521)
[metrics-core-4.1.5.jar:4.1.5]
[junit4] 2>at
com.codahale.metrics.MetricRegistry.register(MetricRegistry.java:154)
[metrics-core-4.1.5.jar:4.1.5]
[junit4] 2>at
org.apache.solr.metrics.SolrMetricManager.registerMetric(SolrMetricManager.java:741)
[java/:?]
[junit4] 2>at
org.apache.solr.metrics.SolrMetricManager.registerGauge(SolrMetricManager.java:779)
[java/:?]
[junit4] 2>at
org.apache.solr.metrics.SolrMetricsContext.gauge(SolrMetricsContext.java:119)
[java/:?]
[junit4] 2>at
org.apache.solr.handler.admin.MetricsHandlerTest$DumpRequestHandler.initializeMetrics(MetricsHandlerTest.java:467)
[test/:?]
[junit4] 2>at
org.apache.solr.metrics.SolrMetricProducer.initializeMetrics(SolrMetricProducer.java:59)
[java/:?]
[junit4] 2>at
org.apache.solr.SolrInfoBeanTest.testCallMBeanInfo(SolrInfoBeanTest.java:70)
[test/:?]
[junit4] 2>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method) ~[?:1.8.0_252]
[junit4] 2>at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
~[?:1.8.0_252]
[junit4] 2>at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[?:1.8.0_252]
[junit4] 2>at java.lang.reflect.Method.invoke(Method.java:498)
~[?:1.8.0_252]
[junit4] 2>at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1750)
[randomizedtesting-runner-2.7.2.jar:?]
[junit4] 2>at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:938)
[randomizedtesting-runner-2.7.2.jar:?]
[junit4] 2>at
com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:974)
[randomizedtesting-runner-2.7.2.jar:?]
[junit4] 2>at
com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:988)
[randomizedtesting-runner-2.7.2.jar:?]
[junit4] 2>at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:57)
[randomizedtesting-runner-2.7.2.jar:?]
[junit4] 2>at org.junit.rules.RunRules.evaluate(RunRules.java:20)
[junit-4.13.1.jar:4.13.1]
[junit4] 2>at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
[java/:?]
[junit4] 2>at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
[java/:?]
[junit4] 2>at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
[java/:?]
[junit4] 2>at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
[java/:?]
[junit4]
[jira] [Commented] (SOLR-6059) Basic support for Cross-Origin resource sharing (CORS) in search requests
[ https://issues.apache.org/jira/browse/SOLR-6059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270382#comment-17270382 ] David Eric Pugh commented on SOLR-6059: --- This has been sitting here for a long time... Would this work with the v2 APIs? I'm faced with the challenge of copying over a custom web.xml to enable CORS ;), and would love something more native.. > Basic support for Cross-Origin resource sharing (CORS) in search requests > - > > Key: SOLR-6059 > URL: https://issues.apache.org/jira/browse/SOLR-6059 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.9, 6.0 >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > Attachments: SOLR-6059.patch > > > Support cross-origin requests to specific search request handlers. > See http://www.w3.org/TR/cors -- 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-operator] HoustonPutman opened a new pull request #199: Change docker image location to apache/
HoustonPutman opened a new pull request #199: URL: https://github.com/apache/lucene-solr-operator/pull/199 Fixes: #194 The non-deployed helm chart will no longer work with the default image name, but that's fine because the released helm chart will continue to work. 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-operator] HoustonPutman opened a new pull request #200: Apachify the solr-operator helm chart
HoustonPutman opened a new pull request #200: URL: https://github.com/apache/lucene-solr-operator/pull/200 A part of: #183 The helm chart needs some updates now that the solr operator is a part of Apache. - The maintainers now start with the Solr Dev Community - Headers have been added to all possible files in the chart - A NOTICE file has been added for the chart as well. 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-15073) Unsafe cast in SystemInfoHandler
[ https://issues.apache.org/jira/browse/SOLR-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270402#comment-17270402 ] ASF subversion and git services commented on SOLR-15073: Commit 9d4811e02f0d3cc4abb46ae00074c5db98c04c07 in lucene-solr's branch refs/heads/master from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=9d4811e ] SOLR-15073: Fix ClassCastException in SystemInfoHandler.getSecurityInfo. Same fix as the #2210 PR commit earlier but this time not extending SystemInfoHandlerTest and also not adding a static SystemInfoHandler.getSecurityInfo variant for test use. > Unsafe cast in SystemInfoHandler > > > Key: SOLR-15073 > URL: https://issues.apache.org/jira/browse/SOLR-15073 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6, 8.7 >Reporter: Nikolay Ivanov >Assignee: Christine Poerschke >Priority: Major > Fix For: 8.8, master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have observed an unsafe cast in > SystemInfoHandler::getSecurityInfo > Is this by design? Currently I have a custom AuthorizationPlugin that > directly implements AuthorizationPlugin interface. With the latest solr > version it is not permitted anymore. A workaround is to extend the > RuleBasedAuthorizationPluginBase, which is not ideal imo. Please share your > thoughts -- 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] [Reopened] (SOLR-14067) Move StatelessScriptUpdateProcessor to a contrib
[ https://issues.apache.org/jira/browse/SOLR-14067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris M. Hostetter reopened SOLR-14067: --- > Move StatelessScriptUpdateProcessor to a contrib > > > Key: SOLR-14067 > URL: https://issues.apache.org/jira/browse/SOLR-14067 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Assignee: David Eric Pugh >Priority: Major > Fix For: master (9.0) > > Time Spent: 7h 10m > Remaining Estimate: 0h > > Move server-side scripting out of core and into a new contrib. This is > better for security. > Former description: > > We should eliminate all scripting capabilities within Solr. Let us start with > the StatelessScriptUpdateProcessor deprecation/removal. -- 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-15102) Create release workflow for Solr docker images
Houston Putman created SOLR-15102: - Summary: Create release workflow for Solr docker images Key: SOLR-15102 URL: https://issues.apache.org/jira/browse/SOLR-15102 Project: Solr Issue Type: Task Security Level: Public (Default Security Level. Issues are Public) Components: Docker Affects Versions: master (9.0) Reporter: Houston Putman Currently the official Solr docker images are built via the docker-solr repository. Starting with 9.0, Solr will be maintaining its own official docker image. Therefore we also need release steps for this. There are a few things that need to be done for this: * Decide how a release image should be built. * Decide how we will support Solr being an Official Docker Image * Make sure that compatibility between local images and official release images is maintained and verified * Add docker image release instructions to the release wizard -- 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-14067) Move StatelessScriptUpdateProcessor to a contrib
[
https://issues.apache.org/jira/browse/SOLR-14067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270424#comment-17270424
]
Christine Poerschke commented on SOLR-14067:
Hello. I did some digging into test failures too this evening and noticed these
two {{lib}} variants, maybe intended, maybe not, just jumped out as surprising
to me.
{code}
$ git grep -h ".lib.*solr\-scripting.*jar"
{code}
> Move StatelessScriptUpdateProcessor to a contrib
>
>
> Key: SOLR-14067
> URL: https://issues.apache.org/jira/browse/SOLR-14067
> Project: Solr
> Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Assignee: David Eric Pugh
>Priority: Major
> Fix For: master (9.0)
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Move server-side scripting out of core and into a new contrib. This is
> better for security.
> Former description:
>
> We should eliminate all scripting capabilities within Solr. Let us start with
> the StatelessScriptUpdateProcessor deprecation/removal.
--
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-operator] HoustonPutman commented on issue #198: Integration tests via Github Actions and Minikube
HoustonPutman commented on issue #198: URL: https://github.com/apache/lucene-solr-operator/issues/198#issuecomment-765686583 Integration tests would be immensely useful for the project, especially if we were able to integrate them with Github Actions! I think that the framework we use, or build, should be flexible enough to use any version of Kubernetes (minikube, microk8s, gcp, eks, etc). That way users could test on their platforms before deploying. However I have no issue starting out with minikube built in, we can always abstract out in the future. Do you know of any integration test frameworks for Kube or should we build something ourselves? 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-14886) Suppress stack trace in Query response.
[
https://issues.apache.org/jira/browse/SOLR-14886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270442#comment-17270442
]
Isabelle Giguere commented on SOLR-14886:
-
We could easily add a parameter in solr.xml to hide (or not) stack traces:
But doing something with that parameter will not be easy.
I thought of a solution that would use that new parameter to modify the
response just before sending it out, so the actual log file would not be
affected. Either adapt implementations of QueryResponseWriter, or method
SolrCore.postDecorateResponse.
However, the "trace" element of the response seems to be set all over the code,
instead of handling the Exception properly, or throwing it so it could be
handled in a more generic way elsewhere. These locations in code (at least 12
that I can see in branch_8x, not counting unit tests) don't all have access to
the config from solr.xml
For example, trying to sort results using a multi-valued field (a date field)
yields this error. The "error" and "trace" elements are set in
QueryComponent.mergeIds.
{code}
class java.lang.String cannot be cast to class org.apache.lucene.util.BytesRef
(java.lang.String is in module java.base of loader 'bootstrap';
org.apache.lucene.util.BytesRef is in unnamed module of loader
org.eclipse.jetty.webapp.WebAppClassLoader @c00fff0)
java.lang.ClassCastException: class java.lang.String cannot be cast to class
org.apache.lucene.util.BytesRef (java.lang.String is in module java.base of
loader 'bootstrap'; org.apache.lucene.util.BytesRef is in unnamed module of
loader org.eclipse.jetty.webapp.WebAppClassLoader @c00fff0) at
org.apache.lucene.search.FieldComparator$TermOrdValComparator.compareValues(FieldComparator.java:561)
at
org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:161)
at
org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardFieldSortedHitQueue.java:153)
at
org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:92)
at
org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardFieldSortedHitQueue.java:33)
at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:254) at
org.apache.lucene.util.PriorityQueue.add(PriorityQueue.java:131) at
org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:147)
at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:958)
at
org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:614)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:593)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:454)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2596) at
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:802) at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:579) at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:420)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:352)
at org.eclipse.jetty.servlet.FilterHolder.doFilter(FilterHolder.java:201) at
org.eclipse.jetty.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1601)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:548)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1435)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1350)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:191)
at
org.eclipse.jetty.server.handler.InetAccessHandler.handle(InetAccessHandler.java:177)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
at
org.eclipse.jetty.server.han
[GitHub] [lucene-solr-operator] sepulworld commented on issue #198: Integration tests via Github Actions and Minikube
sepulworld commented on issue #198: URL: https://github.com/apache/lucene-solr-operator/issues/198#issuecomment-765692729 Agree that whatever we do for integration tests they shouldn't rely on the K8s cluster creation tooling! KUTTL might be worth exploring Kubecon 2020 https://youtu.be/NyHuy40TKyU https://kuttl.dev 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-15073) Unsafe cast in SystemInfoHandler
[ https://issues.apache.org/jira/browse/SOLR-15073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270453#comment-17270453 ] ASF subversion and git services commented on SOLR-15073: Commit 315f26fd70f9a2d254e7ef80fc317276497afe7b in lucene-solr's branch refs/heads/branch_8x from Christine Poerschke [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=315f26f ] SOLR-15073: Fix ClassCastException in SystemInfoHandler.getSecurityInfo. Same fix as the #2210 PR commit earlier but this time not extending SystemInfoHandlerTest and also not adding a static SystemInfoHandler.getSecurityInfo variant for test use. > Unsafe cast in SystemInfoHandler > > > Key: SOLR-15073 > URL: https://issues.apache.org/jira/browse/SOLR-15073 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.6, 8.7 >Reporter: Nikolay Ivanov >Assignee: Christine Poerschke >Priority: Major > Fix For: 8.8, master (9.0) > > Time Spent: 0.5h > Remaining Estimate: 0h > > I have observed an unsafe cast in > SystemInfoHandler::getSecurityInfo > Is this by design? Currently I have a custom AuthorizationPlugin that > directly implements AuthorizationPlugin interface. With the latest solr > version it is not permitted anymore. A workaround is to extend the > RuleBasedAuthorizationPluginBase, which is not ideal imo. Please share your > thoughts -- 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-15096) [REGRESSION] Collection Delete Performance significantly degraded in 9.0 v 8.8
[
https://issues.apache.org/jira/browse/SOLR-15096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270454#comment-17270454
]
Mike Drob commented on SOLR-15096:
--
Comparing logs from an 8x delete:
{noformat}
2021-01-22 21:36:49.195 INFO
(OverseerThreadFactory-18-thread-5-processing-n:10.0.0.160:8983_solr) [ ]
o.a.s.c.a.c.DeleteCollectionCmd Begin Delete Call
2021-01-22 21:36:49.196 INFO
(OverseerCollectionConfigSetProcessor-72063415443980288-10.0.0.160:8983_solr-n_00)
[ ] o.a.s.c.OverseerTaskQueue Response ZK path:
/overseer/collection-queue-work/qnr-08 doesn't exist. Requestor may
have disconnected from ZooKeeper
2021-01-22 21:36:49.196 INFO
(OverseerThreadFactory-18-thread-5-processing-n:10.0.0.160:8983_solr) [ ]
o.a.s.c.a.c.OverseerCollectionMessageHandler Executing Collection
Cmd=action=UNLOAD&deleteInstanceDir=true&deleteDataDir=true&deleteMetricsHistory=true,
asyncId=null
2021-01-22 21:36:49.198 INFO (qtp952562199-27) [ x:coll-3_shard1_replica_n1]
o.a.s.m.SolrMetricManager Closing metric reporters for
registry=solr.core.coll-3.shard1.replica_n1 tag=null
2021-01-22 21:36:49.198 INFO (qtp952562199-27) [ x:coll-3_shard1_replica_n1]
o.a.s.m.r.SolrJmxReporter Closing reporter
[org.apache.solr.metrics.reporters.SolrJmxReporter@5dd69a16: rootName = null,
domain = solr.core.coll-3.shard1.replica_n1, service url = null, agent id =
null] for registry
solr.core.coll-3.shard1.replica_n1/com.codahale.metrics.MetricRegistry@3928453
2021-01-22 21:36:49.201 INFO (qtp952562199-27) [ ] o.a.s.c.SolrCore
[coll-3_shard1_replica_n1] CLOSING SolrCore
org.apache.solr.core.SolrCore@78cdf733
2021-01-22 21:36:49.201 INFO (qtp952562199-27) [ ] o.a.s.m.SolrMetricManager
Closing metric reporters for registry=solr.core.coll-3.shard1.replica_n1
tag=SolrCore@78cdf733
2021-01-22 21:36:49.201 INFO (qtp952562199-27) [ ] o.a.s.m.SolrMetricManager
Closing metric reporters for registry=solr.collection.coll-3.shard1.leader
tag=SolrCore@78cdf733
2021-01-22 21:36:49.201 INFO (qtp952562199-27) [ ]
o.a.s.u.DirectUpdateHandler2 Committing on IndexWriter.close() ... SKIPPED
(unnecessary).
2021-01-22 21:36:49.205 INFO (qtp952562199-27) [ ] o.a.s.c.ZkShardTerms
Successful update of terms at /collections/coll-3/terms/shard1 to
Terms{values={}, version=1}
2021-01-22 21:36:49.207 INFO (qtp952562199-27) [ ] o.a.s.s.HttpSolrCall
[admin] webapp=null path=/admin/cores
params={deleteInstanceDir=true&deleteMetricsHistory=true&core=coll-3_shard1_replica_n1&qt=/admin/cores&deleteDataDir=true&action=UNLOAD&wt=javabin&version=2}
status=0 QTime=10
2021-01-22 21:36:49.209 INFO
(OverseerThreadFactory-18-thread-5-processing-n:10.0.0.160:8983_solr) [ ]
o.a.s.c.c.ZkStateReader Begin waiting for state
2021-01-22 21:36:49.209 INFO
(OverseerThreadFactory-18-thread-5-processing-n:10.0.0.160:8983_solr) [ ]
o.a.s.c.c.ZkStateReader already watching , added to stateWatchers
2021-01-22 21:36:49.312 INFO (zkCallback-10-thread-1) [ ]
o.a.s.c.c.ZkStateReader A cluster state change: [WatchedEvent
state:SyncConnected type:NodeDeleted path:/collections/coll-3/state.json] for
collection [coll-3] has occurred - updating... (live nodes size: [1])
2021-01-22 21:36:49.312 INFO (zkCallback-10-thread-2) [ ]
o.a.s.c.c.ZkStateReader A cluster state change: [WatchedEvent
state:SyncConnected type:NodeDeleted path:/collections/coll-3/state.json] for
collection [coll-3] has occurred - updating... (live nodes size: [1])
2021-01-22 21:36:49.312 INFO (zkCallback-10-thread-3) [ ]
o.a.s.c.c.ZkStateReader A cluster state change: [WatchedEvent
state:SyncConnected type:NodeDeleted path:/collections/coll-3/state.json] for
collection [coll-3] has occurred - updating... (live nodes size: [1])
2021-01-22 21:36:49.312 INFO (zkCallback-10-thread-4) [ ]
o.a.s.c.c.ZkStateReader A cluster state change: [WatchedEvent
state:SyncConnected type:NodeDeleted path:/collections/coll-3/state.json] for
collection [coll-3] has occurred - updating... (live nodes size: [1])
2021-01-22 21:36:49.313 INFO
(OverseerThreadFactory-18-thread-5-processing-n:10.0.0.160:8983_solr) [ ]
o.a.s.c.c.ZkStateReader Exit waiting for state
2021-01-22 21:36:49.318 INFO
(OverseerThreadFactory-18-thread-5-processing-n:10.0.0.160:8983_solr) [ ]
o.a.s.c.a.c.DeleteCollectionCmd End Delete Call
2021-01-22 21:36:49.320 INFO (qtp952562199-30) [ ] o.a.s.s.HttpSolrCall
[admin] webapp=null path=/admin/collections params={name=coll-3&action=DELETE}
status=0 QTime=126
{noformat}
To a 9.0 delete
{noformat}
2021-01-22 21:30:30.632 INFO
(OverseerThreadFactory-15-thread-5-processing-n:localhost:8983_solr) [ ]
o.a.s.c.a.c.DeleteCollectionCmd Begin Delete Call
2021-01-22 21:30:30.657 INFO
(OverseerCollectionConfigSetProcessor-72063388558688256-localhost:8983_solr-n_00)
[ ] o.a.s.c.OverseerTaskQueue Response ZK path:
/overseer/col
[jira] [Created] (LUCENE-9694) New tool for creating a deterministic index
Haoyu Zhai created LUCENE-9694:
--
Summary: New tool for creating a deterministic index
Key: LUCENE-9694
URL: https://issues.apache.org/jira/browse/LUCENE-9694
Project: Lucene - Core
Issue Type: New Feature
Components: general/tools
Reporter: Haoyu Zhai
Lucene's index is segmented, and sometimes number of segments and documents
arrangement greatly impact performance.
Given a stable index sort, our team create a tool that records document
arrangement (called index map) of an index and rearrange another index
(consists of same documents) into the same structure (segment num, and
documents included in each segment).
This tool could be also used in lucene benchmarks for a faster deterministic
index construction (if I understand correctly lucene benchmark is using a
single thread manner to achieve this).
We've already had some discussion in email
[https://markmail.org/message/lbtdntclpnocmfuf]
And I've implemented the first method, using {{IndexWriter.addIndexes}} and a
customized {{FilteredCodecReader}} to achieve the goal. The index construction
time is about 25min and time executing this tool is about 10min.
--
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-14067) Move StatelessScriptUpdateProcessor to a contrib
[ https://issues.apache.org/jira/browse/SOLR-14067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17270459#comment-17270459 ] David Eric Pugh commented on SOLR-14067: Hi all, so, not sure why I thought all the tests passed. Digging through the errors, of course they failed. I havne't done a revert before, waht is the best way to do this? Nervous about making things worse! Digging in: With the ScriptingUpdateRequestProcessor moved to it's own contrib, it seems like that the test for uploading configsets, where we check for the existence of a script, needs the org.apache.solr.scripting.update.ScriptingUpdateRequestProcessor, but of course it's in a contrib. So I think I need to move the test out to the contrib module, or figure out some sort of mock class. I also had the ScriptUpdateProcessorFactory in the example TechProducts, to enable one of the example commands in the Ref Guide page, somewhat similar to the LTR Feature transformer. However, I clearly need to figure out how to get the jars to work, or just remove it. > Move StatelessScriptUpdateProcessor to a contrib > > > Key: SOLR-14067 > URL: https://issues.apache.org/jira/browse/SOLR-14067 > Project: Solr > Issue Type: Improvement >Reporter: Ishan Chattopadhyaya >Assignee: David Eric Pugh >Priority: Major > Fix For: master (9.0) > > Time Spent: 7h 10m > Remaining Estimate: 0h > > Move server-side scripting out of core and into a new contrib. This is > better for security. > Former description: > > We should eliminate all scripting capabilities within Solr. Let us start with > the StatelessScriptUpdateProcessor deprecation/removal. -- 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
