[GitHub] [lucene-solr] dsmiley commented on a change in pull request #1675: SOLR-14652: SolrCore should hold its own CoreDescriptor
dsmiley commented on a change in pull request #1675:
URL: https://github.com/apache/lucene-solr/pull/1675#discussion_r457845217
##
File path: solr/core/src/java/org/apache/solr/core/SolrCore.java
##
@@ -487,10 +488,13 @@ public String getName() {
}
public void setName(String v) {
+Objects.requireNonNull(v);
+boolean renamed = this.name != null && !this.name.equals(v);
+assert !renamed || coreDescriptor.getCloudDescriptor() == null : "Cores
are not renamed in SolrCloud";
Review comment:
I'll file a new issue for that.
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-9322) Discussing a unified vectors format API
[ https://issues.apache.org/jira/browse/LUCENE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161700#comment-17161700 ] Alex Klibisz commented on LUCENE-9322: -- Very briefly, I just remembered another thing you might consider if you are considering storing both dense vectors and sparse vectors. There are two optimizations for sparse vectors at the storage level: # Very obvious, just store the "present/true/positive" indices instead of the full vector. # Maybe less obvious, if you store the indices in sorted order, you can compute intersections more efficiently, which is useful for some similarity functions. For example `int size_of_intersection((0,1,2,3),(2,3,4)) = 2` can be computed with only an int counter and no other intermediate data structures. Whereas, `int size_of_intersection((0,2,1,3),(2,3,4)) = 2` requires converting one of the arrays to a hashset, which adds up at scale. The sorted intersection algo is pretty obvious but here it is in case you need it: [https://github.com/alexklibisz/elastiknn/blob/74815f2613653e2c266bf7eb56b020943dd80b9a/core/src/main/java/com/klibisz/elastiknn/utils/ArrayUtils.java#L10-L36] - Ak > Discussing a unified vectors format API > --- > > Key: LUCENE-9322 > URL: https://issues.apache.org/jira/browse/LUCENE-9322 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Julie Tibshirani >Priority: Major > > Two different approximate nearest neighbor approaches are currently being > developed, one based on HNSW (LUCENE-9004) and another based on coarse > quantization ([#LUCENE-9136]). Each prototype proposes to add a new format to > handle vectors. In LUCENE-9136 we discussed the possibility of a unified API > that could support both approaches. The two ANN strategies give different > trade-offs in terms of speed, memory, and complexity, and it’s likely that > we’ll want to support both. Vector search is also an active research area, > and it would be great to be able to prototype and incorporate new approaches > without introducing more formats. > To me it seems like a good time to begin discussing a unified API. The > prototype for coarse quantization > ([https://github.com/apache/lucene-solr/pull/1314]) could be ready to commit > soon (this depends on everyone's feedback of course). The approach is simple > and shows solid search performance, as seen > [here|https://github.com/apache/lucene-solr/pull/1314#issuecomment-608645326]. > I think this API discussion is an important step in moving that > implementation forward. > The goals of the API would be > # Support for storing and retrieving individual float vectors. > # Support for approximate nearest neighbor search -- given a query vector, > return the indexed vectors that are closest to it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9322) Discussing a unified vectors format API
[
https://issues.apache.org/jira/browse/LUCENE-9322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161697#comment-17161697
]
Julie Tibshirani commented on LUCENE-9322:
--
Hello everyone, I'm sorry for the very late response. Thank you for your
comments on the proposal! And thanks [~alexklibisz] for the suggestions, I will
take a look at the link.
{quote}Personally I would prefer an unified file format for vectors since it is
(theoretically) independent from higher level ANN algorithms. Could we expose
just one "Lucene90VectorsFormat" and low-level I/O, and make only higher logic
(o.a.l.a.index/document/search) to be customizable? Forward iteration is
encouraged anyway...
{quote}
I'm not sure how we could have a completely unified `VectorsFormat`, because
different ANN algorithms require building and maintaining customized data
structures like nearest-neighbor graphs? However it would be great to share the
logic for writing/ reading the original vectors if possible.
{quote}What about different distance metrics like angular and L1 distance? JFYI
I previously implemented switchable distance function on the HNSW branch, if
you have not noticed it…
{quote}
I have the same intuition as Mayya that it’s nice to keep the design simple at
first and just use euclidean distance in the first iteration. It’s possible to
rank based on angular distance using euclidean distance by first normalizing
the document and query vectors to unit length. However I could certainly see
support for maximum inner product search being useful in the future.
{quote}Query part would also need some abstraction and there are many things to
be well thought..., so could we discuss about it in another dedicated issue, to
keep the scope here small ?
{quote}
Right, perhaps we can focus on moving the current proposal forward before
nailing down how it will integrate with `Query`. It will be an interesting
follow-up discussion!
{quote}How would we feel to break this part and commit it separately ?
{quote}
Personally I would be okay with committing basic vector support first, but with
solid APIs/ plugin points for ANN as well. My motivation with considering both
vectors and ANN was to make sure the APIs + codec design could accommodate all
the functionality we think is important.
> Discussing a unified vectors format API
> ---
>
> Key: LUCENE-9322
> URL: https://issues.apache.org/jira/browse/LUCENE-9322
> Project: Lucene - Core
> Issue Type: New Feature
>Reporter: Julie Tibshirani
>Priority: Major
>
> Two different approximate nearest neighbor approaches are currently being
> developed, one based on HNSW (LUCENE-9004) and another based on coarse
> quantization ([#LUCENE-9136]). Each prototype proposes to add a new format to
> handle vectors. In LUCENE-9136 we discussed the possibility of a unified API
> that could support both approaches. The two ANN strategies give different
> trade-offs in terms of speed, memory, and complexity, and it’s likely that
> we’ll want to support both. Vector search is also an active research area,
> and it would be great to be able to prototype and incorporate new approaches
> without introducing more formats.
> To me it seems like a good time to begin discussing a unified API. The
> prototype for coarse quantization
> ([https://github.com/apache/lucene-solr/pull/1314]) could be ready to commit
> soon (this depends on everyone's feedback of course). The approach is simple
> and shows solid search performance, as seen
> [here|https://github.com/apache/lucene-solr/pull/1314#issuecomment-608645326].
> I think this API discussion is an important step in moving that
> implementation forward.
> The goals of the API would be
> # Support for storing and retrieving individual float vectors.
> # Support for approximate nearest neighbor search -- given a query vector,
> return the indexed vectors that are closest to it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161687#comment-17161687 ] Tomoko Uchida commented on LUCENE-9312: --- bq. Please take a look at the commit and let me know if it works Anyway, the changes woks fine for me (MacOS and Linux), thank you! > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161684#comment-17161684
]
Tomoko Uchida commented on LUCENE-9312:
---
Off-topic: I had to set those fork options in "defaults-java.gradle" to show
javac error messages in English (my default locale is ja_JP; Java seems to have
lots of Japanese translation resource for better or worse...).
{code:java}
+++ b/gradle/defaults-java.gradle
@@ -25,6 +25,7 @@ allprojects {
// Use 'release' flag instead of 'source' and 'target'
tasks.withType(JavaCompile) {
options.compilerArgs += ["--release", "11"]
+ options.forkOptions.jvmArgs += ["-J-Duser.country=US",
"-J-Duser.language=en_US"]
}
{code}
Same options are already set in "render-javadoc.gradle", I'd like to have them
in default-java.gradle too, though am not sure where is the proper location for
them.
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161639#comment-17161639
]
Tomoko Uchida edited comment on LUCENE-9312 at 7/21/20, 3:23 AM:
-
I checked out the latest commits and run (whole) {{javadoc}} task. It works for
me with or without {{-Druntime.java.home}} option. ({{solr/core}} project seems
to fail with jdk12+ due to Java compilation error; but this should be another
matter)
{code:java}
lucene-solr $ ./gradlew -Druntime.java.home=/usr/local/java/adoptopenjdk/jdk12
javadoc
> Task :altJvmWarning
NOTE: Alternative java toolchain will be used for compilation and tests:
Project will use Java 12 from: /usr/local/java/adoptopenjdk/jdk-12.0.2+10
Gradle runs with Java 11 from: /usr/local/java/adoptopenjdk/jdk-11.0.3+7
...
> Task :solr:core:compileJava
warning: [path] bad path element
"/Users/tomoko.uchida/repo-other/lucene-solr/solr/server/build/classes/java/main":
no such file or directory
error: warnings found and -Werror specified
1 error
1 warning
> Task :solr:core:compileJava FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':solr:core:compileJava'.
> Compilation failed with exit code 1; see the compiler error output for
> details.
{code}
was (Author: tomoko uchida):
I checked out the latest commits and run (whole) {{javadoc}} task. It works for
me with or without {{-Druntime.java.home}} option. ({{solr/core}} project
seems to fail with jdk12+ due to Java compilation error; but this should be
another matter)
{code}
lucene-solr $ ./gradlew -Druntime.java.home=/usr/local/java/adoptopenjdk/jdk12
javadoc
> Task :altJvmWarning
NOTE: Alternative java toolchain will be used for compilation and tests:
Project will use Java 12 from: /usr/local/java/adoptopenjdk/jdk-12.0.2+10
Gradle runs with Java 11 from: /usr/local/java/adoptopenjdk/jdk-11.0.3+7
...
> Task :solr:core:compileJava FAILED
...
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':solr:core:compileJava'.
> Compilation failed with exit code 1; see the compiler error output for
> details.
{code}
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[
https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161665#comment-17161665
]
Lucene/Solr QA commented on LUCENE-9437:
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
|| || || || {color:brown} Prechecks {color} ||
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
18s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
13s{color} | {color:red} facet in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 13s{color}
| {color:red} facet in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Release audit (RAT) {color} | {color:red}
0m 13s{color} | {color:red} facet in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Check forbidden APIs {color} | {color:red}
0m 13s{color} | {color:red} facet in the patch failed. {color} |
| {color:red}-1{color} | {color:red} Validate source patterns {color} |
{color:red} 0m 13s{color} | {color:red} facet in the patch failed. {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 4s{color}
| {color:red} facet in the patch failed. {color} |
| {color:black}{color} | {color:black} {color} | {color:black} 0m 45s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | LUCENE-9437 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/13008042/LUCENE-9437.patch |
| Optional Tests | compile javac unit ratsources checkforbiddenapis
validatesourcepatterns |
| uname | Linux lucene1-us-west 4.15.0-108-generic #109-Ubuntu SMP Fri Jun 19
11:33:10 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | ant |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-LUCENE-Build/sourcedir/dev-tools/test-patch/lucene-solr-yetus-personality.sh
|
| git revision | master / 48e92ba9c74 |
| ant | version: Apache Ant(TM) version 1.10.5 compiled on March 28 2019 |
| Default Java | LTS |
| compile |
https://builds.apache.org/job/PreCommit-LUCENE-Build/285/artifact/out/patch-compile-lucene_facet.txt
|
| javac |
https://builds.apache.org/job/PreCommit-LUCENE-Build/285/artifact/out/patch-compile-lucene_facet.txt
|
| Release audit (RAT) |
https://builds.apache.org/job/PreCommit-LUCENE-Build/285/artifact/out/patch-compile-lucene_facet.txt
|
| Check forbidden APIs |
https://builds.apache.org/job/PreCommit-LUCENE-Build/285/artifact/out/patch-compile-lucene_facet.txt
|
| Validate source patterns |
https://builds.apache.org/job/PreCommit-LUCENE-Build/285/artifact/out/patch-compile-lucene_facet.txt
|
| unit |
https://builds.apache.org/job/PreCommit-LUCENE-Build/285/artifact/out/patch-unit-lucene_facet.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-LUCENE-Build/285/testReport/ |
| modules | C: lucene/facet U: lucene/facet |
| Console output |
https://builds.apache.org/job/PreCommit-LUCENE-Build/285/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly
> accessible
> -
>
> Key: LUCENE-9437
> URL: https://issues.apache.org/jira/browse/LUCENE-9437
> Project: Lucene - Core
> Issue Type: Improvement
>Affects Versions: 8.6
>Reporter: Ankur
>Priority: Trivial
> Attachments: LUCENE-9437.patch
>
>
> Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is
> set to 'protected'. This prevents the method from being used outside this
> class in a setting where BinaryDocValues reader is instantiated outside the
> class and binary payload containing ordinals still needs to be decoded.
--
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-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[ https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankur updated LUCENE-9437: -- Description: Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is set to 'protected'. This prevents the method from being used outside this class in a setting where BinaryDocValues reader is instantiated outside the class and binary payload containing ordinals still needs to be decoded. (was: Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is set to 'protected'. This prevents the method from being used outside this class in a setting where BinaryDocValues reader is instantiated outside the class and binary payload containing ordinals still need to be decoded.) > Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly > accessible > - > > Key: LUCENE-9437 > URL: https://issues.apache.org/jira/browse/LUCENE-9437 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 8.6 >Reporter: Ankur >Priority: Trivial > Attachments: LUCENE-9437.patch > > > Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is > set to 'protected'. This prevents the method from being used outside this > class in a setting where BinaryDocValues reader is instantiated outside the > class and binary payload containing ordinals still needs to be decoded. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
noblepaul commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r457779024
##
File path: solr/core/src/java/org/apache/solr/cloud/gumi/PropertyKeyFactory.java
##
@@ -0,0 +1,34 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * Factory used by the plugin to create property keys to request property
values from Solr
+ */
+public interface PropertyKeyFactory {
Review comment:
PrpertyKey can be an enum?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] noblepaul commented on a change in pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
noblepaul commented on a change in pull request #1684:
URL: https://github.com/apache/lucene-solr/pull/1684#discussion_r45268
##
File path: solr/core/src/java/org/apache/solr/cloud/gumi/Replica.java
##
@@ -0,0 +1,34 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * An instantiation (or one of the copies) of a given {@link Shard} of a given
{@link SolrCollection}.
+ * Objects of this type are returned by the Solr framework to the plugin, they
are not built by the plugin. When the
+ * plugin wants to add a replica it goes through {@link
WorkOrderFactory#createWorkOrderCreateReplica}).
+ * TODO is there an elegant way to have this type also used by the plugin to
add replicas? (insisting on elegant)
+ */
+public interface Replica {
Review comment:
Do we need to add a class for this? Isn't it good enough to use the
existing class?
##
File path: solr/core/src/java/org/apache/solr/cloud/gumi/PropertyKeyFactory.java
##
@@ -0,0 +1,34 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * Factory used by the plugin to create property keys to request property
values from Solr
+ */
+public interface PropertyKeyFactory {
Review comment:
PrpertyKey can be an enum?
##
File path:
solr/core/src/java/org/apache/solr/cloud/gumi/CreateCollectionRequest.java
##
@@ -0,0 +1,35 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.solr.cloud.gumi;
+
+/**
+ * Request for creating a new collection with a given number of shards and
replication factor for various replica types.
+ *
+ * Note there is no need at this stage to allow the request to convey each
shard hash range for example, this can be handled
+ * by the Solr side implementation without needing the plugin to worry about
it.
+ *
+ */
+public interface CreateCollectionRequest extends Request {
+ String getCollectionName();
+
+ int getShardCount();
+
+ int getNRTReplicationFactor();
Review comment:
`getNrtReplicaCount()` ? and so on ?
##
File path: solr/core/src/java/org/apache/solr/cloud/gumi/ReplicaType.java
##
@@ -0,0 +1,25 @@
+/*
+ * 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/li
[jira] [Updated] (SOLR-14613) Provide a clean API for pluggable replica assignment implementations
[
https://issues.apache.org/jira/browse/SOLR-14613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-14613:
--
Summary: Provide a clean API for pluggable replica assignment
implementations (was: Provide a clean API for pluggable autoscaling
implementations)
> Provide a clean API for pluggable replica assignment implementations
>
>
> Key: SOLR-14613
> URL: https://issues.apache.org/jira/browse/SOLR-14613
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
>Reporter: Andrzej Bialecki
>Priority: Major
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> As described in SIP-8 the current autoscaling Policy implementation has
> several limitations that make it difficult to use for very large clusters and
> very large collections. SIP-8 also mentions the possible migration path by
> providing alternative implementations of the placement strategies that are
> less complex but more efficient in these very large environments.
> We should review the existing APIs that the current autoscaling engine uses
> ({{SolrCloudManager}} , {{AssignStrategy}} , {{Suggester}} and related
> interfaces) to see if they provide a sufficient and minimal API for plugging
> in alternative autoscaling placement strategies, and if necessary refactor
> the existing APIs.
> Since these APIs are internal it should be possible to do this without
> breaking back-compat.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161639#comment-17161639
]
Tomoko Uchida commented on LUCENE-9312:
---
I checked out the latest commits and run (whole) {{javadoc}} task. It works for
me with or without {{-Druntime.java.home}} option. ({{solr/core}} project
seems to fail with jdk12+ due to Java compilation error; but this should be
another matter)
{code}
lucene-solr $ ./gradlew -Druntime.java.home=/usr/local/java/adoptopenjdk/jdk12
javadoc
> Task :altJvmWarning
NOTE: Alternative java toolchain will be used for compilation and tests:
Project will use Java 12 from: /usr/local/java/adoptopenjdk/jdk-12.0.2+10
Gradle runs with Java 11 from: /usr/local/java/adoptopenjdk/jdk-11.0.3+7
...
> Task :solr:core:compileJava FAILED
...
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':solr:core:compileJava'.
> Compilation failed with exit code 1; see the compiler error output for
> details.
{code}
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Created] (SOLR-14670) Add support for standalone mode in HealthCheckHandler
Tomas Eduardo Fernandez Lobbe created SOLR-14670:
Summary: Add support for standalone mode in HealthCheckHandler
Key: SOLR-14670
URL: https://issues.apache.org/jira/browse/SOLR-14670
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Reporter: Tomas Eduardo Fernandez Lobbe
{{HealthCheckHandler}} currently explicitly states that it doesn't support
standalone mode. I think something simple as checking that the CoreContainer
exists and it's not shutting down may be enough (alternative, we can check for
init failures too). This could be useful to use as healthcheck in Docker images
not running in SolrCloud mode.
--
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-site] anshumg opened a new pull request #23: Mark Doron Cohen as Emeritus PMC member
anshumg opened a new pull request #23: URL: https://github.com/apache/lucene-site/pull/23 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-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161627#comment-17161627
]
Mark Robert Miller commented on SOLR-14636:
---
Now the great stuff is starting to pop. But still all stuff I remember! I don’t
even know what happened to that efforts code. It was tons and tons of work on
the starburst branch that I did push, but at the time was switching jobs and
making a movie and a year later I realized it was a version missing like 1.5-2
months of work. Could never find it.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> {color:#de350b}NOTE: Just entered a period of likely instability as I clear
> out the new room of zombies.{color}
> *tests***:
> * *core*: {color:#00875a}*solid*{color} with *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*solid*{color} with {color:#de350b}*ignores*{color}
> * *test-framework*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson opened a new pull request #1685: LUCENE-9433: Remove Ant support from trunk
ErickErickson opened a new pull request #1685: URL: https://github.com/apache/lucene-solr/pull/1685 This adds the first pass at changing the documentation, especially README.md and ref guide files. lucene/README.md is a major question, currently it has a nocommit in 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
[jira] [Updated] (LUCENE-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated LUCENE-9433: --- Description: Items that may need to be addressed: * -Testing with OpenJDK early access releases- * Mavenizing * Test speed (?) * Update any mentions of ant in the ref guide * Update Confluence, in particular "how to contribute" * Update Jenkins to not try to run ant anything * make an eclipse task (netbeans too?) * various documentation (e.g. README/INSTALL) files still needs to be converted to gradle * fix some relative links in javadocs which contain ant module names * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, and some in the README.md. This one should probably be its own JIRA since it'll require quite a bit of verification... was: Items that may need to be addressed: * Testing with OpenJDK early access releases * Mavenizing * Test speed (?) * Update any mentions of ant in the ref guide * Update Confluence, in particular "how to contribute" * Update Jenkins to not try to run ant anything * make an eclipse task * various documentation (e.g. README/INSTALL) files still needs to be converted to gradle * fix some relative links in javadocs which contain ant module names > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Items that may need to be addressed: > * -Testing with OpenJDK early access releases- > * Mavenizing > * Test speed (?) > * Update any mentions of ant in the ref guide > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task (netbeans too?) > * various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle > * fix some relative links in javadocs which contain ant module names > * dev-tools/scripts/* There are a lot of mentions of ant in the *.py* files, > and some in the README.md. This one should probably be its own JIRA since > it'll require quite a bit of verification... -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson commented on pull request #1680: LUCENE-9433: Remove Ant support from trunk
ErickErickson commented on pull request #1680: URL: https://github.com/apache/lucene-solr/pull/1680#issuecomment-661424104 Closing, new PR available. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] ErickErickson closed pull request #1680: LUCENE-9433: Remove Ant support from trunk
ErickErickson closed pull request #1680: URL: https://github.com/apache/lucene-solr/pull/1680 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-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161603#comment-17161603 ] Erick Erickson commented on LUCENE-9433: How do we want to deal with lucene/README.md? At this point is it even possible to build Lucene without having the parent directory? Ideas: 1 - Make it a placeholder and point them at Solr and tell them how to build lucene only, ignoring solr (e.g. ./gradlew -p lucene assemble) from the full Solr distro. 2 - Do whatever's necessary to make Lucene self contained and still play nice with the combined build and document that. IDK what that would be mind you... 3 - Make it a placeholder with a notation about Solr moving to a TLP and fix it up then. 4 - ?? > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Items that may need to be addressed: > * Testing with OpenJDK early access releases > * Mavenizing > * Test speed (?) > * Update any mentions of ant in the ref guide > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task > * various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle > * fix some relative links in javadocs which contain ant module names -- 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-14669) Solr 8.6 / ZK 3.6.1 / Admin UI - ZK Status Null
[ https://issues.apache.org/jira/browse/SOLR-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161602#comment-17161602 ] Erick Erickson commented on SOLR-14669: --- Hmmm, this seems identical to SOLR-14463, but the claim is that's fixed in Solr 8.6. [~janhoy] any comments? > Solr 8.6 / ZK 3.6.1 / Admin UI - ZK Status Null > --- > > Key: SOLR-14669 > URL: https://issues.apache.org/jira/browse/SOLR-14669 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: Admin UI, SolrCloud >Affects Versions: 8.6 >Reporter: Jörn Franke >Priority: Minor > > When opening the Admin UI / ZK Status page it shows just null. Solr 8.6.0 / > ZK 3.6.1. Zk is a 3 node ensemble. > It seems to be cosmetic in the UI - otherwise Solr seems to work fine. > Deleted already browser cache and restarted browser. Issue persists. > In the logfiles I find the following error: > 2020-07-20 16:34:27.853 ERROR (qtp767511741-2227) [ ] > o.a.s.h.RequestHandlerBase java.lang.NumberFormatException: For input string: > "null" > at > java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) > at java.base/java.lang.Integer.parseInt(Integer.java:652) > at java.base/java.lang.Integer.parseInt(Integer.java:770) > at > org.apache.solr.handler.admin.ZookeeperStatusHandler.getZkStatus(ZookeeperStatusHandler.java:116) > at > org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:78) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211) > at > org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:839) > at > org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:805) > at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:558) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:419) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678) > at > org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at > org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) > at org.eclipse.jetty.server.Server.handle(Server.java:505) > at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) > at > org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > at > org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427) > at > org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321) > at > org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) > at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) > at org.eclipse.jetty.io.ChannelEndPo
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161596#comment-17161596
]
Mark Robert Miller commented on SOLR-14636:
---
Alright, back to ez mode, but I am super happy about where I ended up. I’ll
like flip the status to beta within a week or too, essentially meaning you
could try to run it outside of tests with some confidence of not getting poked
in the eye.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> {color:#de350b}NOTE: Just entered a period of likely instability as I clear
> out the new room of zombies.{color}
> *tests***:
> * *core*: {color:#00875a}*solid*{color} with *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*solid*{color} with {color:#de350b}*ignores*{color}
> * *test-framework*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
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-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[ https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankur updated LUCENE-9437: -- Status: Patch Available (was: Open) > Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly > accessible > - > > Key: LUCENE-9437 > URL: https://issues.apache.org/jira/browse/LUCENE-9437 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 8.6 >Reporter: Ankur >Priority: Trivial > Attachments: LUCENE-9437.patch > > > Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is > set to 'protected'. This prevents the method from being used outside this > class in a setting where BinaryDocValues reader is instantiated outside the > class and binary payload containing ordinals still need to be decoded. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[ https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161587#comment-17161587 ] Ankur commented on LUCENE-9437: --- Simple code change to raise the visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method from 'protected' to 'public'. Also added javadoc > Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly > accessible > - > > Key: LUCENE-9437 > URL: https://issues.apache.org/jira/browse/LUCENE-9437 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 8.6 >Reporter: Ankur >Priority: Trivial > Attachments: LUCENE-9437.patch > > > Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is > set to 'protected'. This prevents the method from being used outside this > class in a setting where BinaryDocValues reader is instantiated outside the > class and binary payload containing ordinals still need to be decoded. -- 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-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
[ https://issues.apache.org/jira/browse/LUCENE-9437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ankur updated LUCENE-9437: -- Attachment: LUCENE-9437.patch Lucene Fields: New,Patch Available (was: New) Affects Version/s: 8.6 Status: Open (was: Open) > Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly > accessible > - > > Key: LUCENE-9437 > URL: https://issues.apache.org/jira/browse/LUCENE-9437 > Project: Lucene - Core > Issue Type: Improvement >Affects Versions: 8.6 >Reporter: Ankur >Priority: Trivial > Attachments: LUCENE-9437.patch > > > Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is > set to 'protected'. This prevents the method from being used outside this > class in a setting where BinaryDocValues reader is instantiated outside the > class and binary payload containing ordinals still need to be decoded. -- 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] (LUCENE-9437) Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible
Ankur created LUCENE-9437: - Summary: Make DocValuesOrdinalsReader.decode(BytesRef, IntsRef) method publicly accessible Key: LUCENE-9437 URL: https://issues.apache.org/jira/browse/LUCENE-9437 Project: Lucene - Core Issue Type: Improvement Reporter: Ankur Visibility of _DocValuesOrdinalsReader.decode(BytesRef, IntsRef)_ method is set to 'protected'. This prevents the method from being used outside this class in a setting where BinaryDocValues reader is instantiated outside the class and binary payload containing ordinals still need to be decoded. -- 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-14613) Provide a clean API for pluggable autoscaling implementations
[
https://issues.apache.org/jira/browse/SOLR-14613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161576#comment-17161576
]
Ilan Ginzburg commented on SOLR-14613:
--
Easiest way to look at this is to start with the two examples
{{SamplePluginMinimizeCores}} and {{SamplePluginRandomPlacement}}.
Or {{GumiPlugin}}.
> Provide a clean API for pluggable autoscaling implementations
> -
>
> Key: SOLR-14613
> URL: https://issues.apache.org/jira/browse/SOLR-14613
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
>Reporter: Andrzej Bialecki
>Priority: Major
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> As described in SIP-8 the current autoscaling Policy implementation has
> several limitations that make it difficult to use for very large clusters and
> very large collections. SIP-8 also mentions the possible migration path by
> providing alternative implementations of the placement strategies that are
> less complex but more efficient in these very large environments.
> We should review the existing APIs that the current autoscaling engine uses
> ({{SolrCloudManager}} , {{AssignStrategy}} , {{Suggester}} and related
> interfaces) to see if they provide a sufficient and minimal API for plugging
> in alternative autoscaling placement strategies, and if necessary refactor
> the existing APIs.
> Since these APIs are internal it should be possible to do this without
> breaking back-compat.
--
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-14613) Provide a clean API for pluggable autoscaling implementations
[
https://issues.apache.org/jira/browse/SOLR-14613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161574#comment-17161574
]
Ilan Ginzburg commented on SOLR-14613:
--
Initial milestone of my thinking. Not complete by any means but you should have
a clear idea of where I want to take this.
Feedback (of any type, constructive or not) +*very much welcome*+.
[https://github.com/apache/lucene-solr/pull/1684]
[~ichattopadhyaya] [~noble.paul] [~ab] [~erickerickson]
> Provide a clean API for pluggable autoscaling implementations
> -
>
> Key: SOLR-14613
> URL: https://issues.apache.org/jira/browse/SOLR-14613
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
>Reporter: Andrzej Bialecki
>Priority: Major
> Time Spent: 5h 50m
> Remaining Estimate: 0h
>
> As described in SIP-8 the current autoscaling Policy implementation has
> several limitations that make it difficult to use for very large clusters and
> very large collections. SIP-8 also mentions the possible migration path by
> providing alternative implementations of the placement strategies that are
> less complex but more efficient in these very large environments.
> We should review the existing APIs that the current autoscaling engine uses
> ({{SolrCloudManager}} , {{AssignStrategy}} , {{Suggester}} and related
> interfaces) to see if they provide a sufficient and minimal API for plugging
> in alternative autoscaling placement strategies, and if necessary refactor
> the existing APIs.
> Since these APIs are internal it should be possible to do this without
> breaking back-compat.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] murblanc opened a new pull request #1684: SOLR-14613: strongly typed initial proposal for plugin interface
murblanc opened a new pull request #1684: URL: https://github.com/apache/lucene-solr/pull/1684 SOLR-14613: strongly typed initial proposal for plugin interface to replace Autoscaling This is not meant to be merged, it's to share early for feedback. Still WIP, any feedback most welcome before I invest more time. 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] [Comment Edited] (SOLR-12847) Cut over implementation of maxShardsPerNode to a collection policy
[ https://issues.apache.org/jira/browse/SOLR-12847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161571#comment-17161571 ] Gus Heck edited comment on SOLR-12847 at 7/20/20, 10:05 PM: FWIW when I was investigating and fixing the MOVEREPLICA docs I found that maxShardsPerNode is advisory only once the collection is created and in not a hard limit. If destination node is specified in ADDREPLICA it will force placement above the limit and move replica always issues its add with a specified value for the node. Thus, MOVEREPLICA entirely ignores maxShardsPerNode. SOLR-13169 was (Author: gus_heck): FWIW when I was investigating and fixing the MOVEREPLICA docs I found that maxShardsPerNode is advisory only once the collection is created and in not a hard limit. If destination node is specified in ADDREPLICA it will force placement above the limit and move replica always issues its add with a specified value for the node. Thus, MOVEREPLICA entirely ignores maxShardsPerNode. > Cut over implementation of maxShardsPerNode to a collection policy > -- > > Key: SOLR-12847 > URL: https://issues.apache.org/jira/browse/SOLR-12847 > Project: Solr > Issue Type: Bug > Components: AutoScaling, SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki >Priority: Major > Fix For: master (9.0) > > Time Spent: 40m > Remaining Estimate: 0h > > We've back and forth over handling maxShardsPerNode with autoscaling policies > (see SOLR-11005 for history). Now that we've reimplemented support for > creating collections with maxShardsPerNode when autoscaling policy is > enabled, we should re-look at how it is implemented. > I propose that we fold maxShardsPerNode (if specified) to a collection level > policy that overrides the corresponding default in cluster policy (see > SOLR-12845). We'll need to ensure that if maxShardsPerNode is specified then > the user sees neither violations nor corresponding suggestions because of the > default cluster policy. -- 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-12847) Cut over implementation of maxShardsPerNode to a collection policy
[ https://issues.apache.org/jira/browse/SOLR-12847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161571#comment-17161571 ] Gus Heck commented on SOLR-12847: - FWIW when I was investigating and fixing the MOVEREPLICA docs I found that maxShardsPerNode is advisory only once the collection is created and in not a hard limit. If destination node is specified in ADDREPLICA it will force placement above the limit and move replica always issues its add with a specified value for the node. Thus, MOVEREPLICA entirely ignores maxShardsPerNode. > Cut over implementation of maxShardsPerNode to a collection policy > -- > > Key: SOLR-12847 > URL: https://issues.apache.org/jira/browse/SOLR-12847 > Project: Solr > Issue Type: Bug > Components: AutoScaling, SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Andrzej Bialecki >Priority: Major > Fix For: master (9.0) > > Time Spent: 40m > Remaining Estimate: 0h > > We've back and forth over handling maxShardsPerNode with autoscaling policies > (see SOLR-11005 for history). Now that we've reimplemented support for > creating collections with maxShardsPerNode when autoscaling policy is > enabled, we should re-look at how it is implemented. > I propose that we fold maxShardsPerNode (if specified) to a collection level > policy that overrides the corresponding default in cluster policy (see > SOLR-12845). We'll need to ensure that if maxShardsPerNode is specified then > the user sees neither violations nor corresponding suggestions because of the > default cluster policy. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14656) Deprecate current autoscaling framework, remove from master
[
https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17160311#comment-17160311
]
Ishan Chattopadhyaya edited comment on SOLR-14656 at 7/20/20, 9:16 PM:
---
Here are collection creation times, as more and more collections are created.
The blue line is on master, the red line on the branch in this PR (where
autoscaling framework has been removed).
!Screenshot from 2020-07-18 07-49-01.png!
(Methodology: On a beefy machine, create 50 Solr JVMs, 1GB RAM each. Then, in a
loop, keep creating collections with 3 shards)
NOTE: This should reproduce on lesser JVMs, lower RAM too.
{code:java}
# Start Solr nodes:
bin/solr -c -m 1g
for i in {1..49}; do PORT=8983; echo $i; bin/solr -c -m 1g -z localhost:9983 -p
$((PORT+i)); done
# Create tons of collections
for i in {1..2000}; do echo $i; curl
"http://localhost:8983/solr/admin/collections?action=CREATE&name=col$i&numShards=3";;
done > collection-creation-times.log
{code}
was (Author: ichattopadhyaya):
Here are collection creation times, as more and more collections are created.
The blue line is on master, the red line on the branch in this PR (where
autoscaling framework has been removed).
!Screenshot from 2020-07-18 07-49-01.png!
(Methodology: On a beefy machine, create 50 Solr JVMs, 1GB RAM each. Then, in a
loop, keep creating collections with 3 shards)
{code}
# Start Solr nodes:
bin/solr -c -m 1g
for i in {1..49}; do PORT=8983; echo $i; bin/solr -c -m 1g -z localhost:9983 -p
$((PORT+i)); done
# Create tons of collections
for i in {1..2000}; do echo $i; curl
"http://localhost:8983/solr/admin/collections?action=CREATE&name=col$i&numShards=3";;
done > collection-creation-times.log
{code}
> Deprecate current autoscaling framework, remove from master
> ---
>
> Key: SOLR-14656
> URL: https://issues.apache.org/jira/browse/SOLR-14656
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: Screenshot from 2020-07-18 07-49-01.png
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> The autoscaling framework is being re-designed in SOLR-14613 (SIP:
> https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2).
> The current autoscaling framework is very inefficient, improperly designed
> and too bloated and doesn't receive the level of support we aspire to provide
> for all components that we ship.
> This issue is to deprecate current autoscaling framework in 8x, so we can
> focus on the new autoscaling framework afresh.
--
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-14656) Deprecate current autoscaling framework, remove from master
[ https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161489#comment-17161489 ] ASF subversion and git services commented on SOLR-14656: Commit b46321e19e2bea1981c5a22a9db4d9236a06f146 in lucene-solr's branch refs/heads/jira/LUCENE-9312 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b46321e ] SOLR-14656: Adding back REPLACENODE documentation that was omitted by mistake > Deprecate current autoscaling framework, remove from master > --- > > Key: SOLR-14656 > URL: https://issues.apache.org/jira/browse/SOLR-14656 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: Screenshot from 2020-07-18 07-49-01.png > > Time Spent: 3h > Remaining Estimate: 0h > > The autoscaling framework is being re-designed in SOLR-14613 (SIP: > https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2). > The current autoscaling framework is very inefficient, improperly designed > and too bloated and doesn't receive the level of support we aspire to provide > for all components that we ship. > This issue is to deprecate current autoscaling framework in 8x, so we can > focus on the new autoscaling framework afresh. -- 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-14656) Deprecate current autoscaling framework, remove from master
[ https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161488#comment-17161488 ] ASF subversion and git services commented on SOLR-14656: Commit cc0c111949d5039a0c7cb67cad55c63e2f761298 in lucene-solr's branch refs/heads/jira/LUCENE-9312 from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cc0c111 ] SOLR-14656: Removing Autoscaling Framework The following were removed: * Autoscaling policy, triggers etc. * withCollection handling * UTILIZENODE command * Sim framework * Suggestions tab in UI * Reference guide pages for autoscaling * autoAddReplicas feature * UTILIZENODE > Deprecate current autoscaling framework, remove from master > --- > > Key: SOLR-14656 > URL: https://issues.apache.org/jira/browse/SOLR-14656 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: Screenshot from 2020-07-18 07-49-01.png > > Time Spent: 3h > Remaining Estimate: 0h > > The autoscaling framework is being re-designed in SOLR-14613 (SIP: > https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2). > The current autoscaling framework is very inefficient, improperly designed > and too bloated and doesn't receive the level of support we aspire to provide > for all components that we ship. > This issue is to deprecate current autoscaling framework in 8x, so we can > focus on the new autoscaling framework afresh. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161491#comment-17161491 ] ASF subversion and git services commented on LUCENE-9312: - Commit a8fdda60f944e12854f669b0e7003a73523b30b8 in lucene-solr's branch refs/heads/jira/LUCENE-9312 from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=a8fdda6 ] Merge branch 'master' into jira/LUCENE-9312 > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-13205) StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
[
https://issues.apache.org/jira/browse/SOLR-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161490#comment-17161490
]
ASF subversion and git services commented on SOLR-13205:
Commit 48e92ba9c74ebf204308793d9a00bc48b2780136 in lucene-solr's branch
refs/heads/jira/LUCENE-9312 from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=48e92ba ]
SOLR-13205: Improve empty-string handling in SolrQueryParserBase
Contributed-By: pramodkumar9
> StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
>
>
> Key: SOLR-13205
> URL: https://issues.apache.org/jira/browse/SOLR-13205
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection and reproducing the bug
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html].
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will
> allow you to reproduce the issue reported.
>Reporter: Johannes Kloos
>Assignee: Jason Gerlowski
>Priority: Minor
> Labels: diffblue, newdev
> Attachments: SOLR-13205.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?df=&explainOther=debug=all&debugQuery=on
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:658)
> at
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:1045)
> at
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:801)
> at org.apache.solr.parser.QueryParser.Term(QueryParser.java:421)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:278)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:255)
> at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)
> at org.apache.solr.search.QParser.getQuery(QParser.java:173)
> at
> org.apache.solr.util.SolrPluginUtils.doSimpleQuery(SolrPluginUtils.java:479)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardResultsDebug(SolrPluginUtils.java:390)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardDebug(SolrPluginUtils.java:343)
> at
> org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:100)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:306)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> {noformat}
> The “df” parameter means that we set the empty string as default field(!).
> Since we do not give a field in the query, the default field is substituted
> in getFieldQuery. We then check if the field starts with “_” by using
> charAt(0).
> A trivial fix would be to replace field.charAt(0) == ‘_’ with
> field.startsWith(“_”).
> To set up an environment to reproduce this bug, follow the description in the
> ‘Environment’ field.
> We automatically found this
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161485#comment-17161485
]
Dawid Weiss commented on LUCENE-9312:
-
I changed your patch slightly, Tomoko. I used public Gradle APIs (they're
relatively new and still in beta, but still worth to switch from internal) and
I reorganized the logic of how the executable is resolved and passed to mimic
that of gradle's javadoc task. Please take a look at the commit and let me know
if it works (works for me when you override {{-Pruntime.java.home=...}}).
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on pull request #1682: Use FileSystem.newInstance instead of get in HDFSBackupRepository
atris commented on pull request #1682: URL: https://github.com/apache/lucene-solr/pull/1682#issuecomment-661265076 Tests pass -- no regressions. @mkhludnev Any thoughts? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14583) Spell suggestion is returned even if hits are non-zero when spellcheck.maxResultsForSuggest=0
[
https://issues.apache.org/jira/browse/SOLR-14583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161426#comment-17161426
]
Munendra S N commented on SOLR-14583:
-
The expectation is that {{maxResultsForSuggest=0}} with onlyMorePopular
enabled, and number of doc hits is greater than 0, suggestion shouldn't be
returned but currently, it does return the suggestion. The same doesn't happen
if {{maxResultsForSuggest>0}} with onlyMorePopular is enabled.
The above behavior is consistent with either extendedResults enabled or
disabled.
{quote}In any case, we probably shouldn't make breaking API changes unless we
can demonstrate a clear benefit to the user{quote}
+1. Even we decide to allow user to specify suggestMode, it could behave
similar to facet.method in json facet where specified value along with other
conditions(field type,multivalued) is considered before choosing the facet
method. Similarly, spellcheck component choose the mode based on the
combination of specified value and other conditions like hits but that would
entirely be different task.
> Spell suggestion is returned even if hits are non-zero when
> spellcheck.maxResultsForSuggest=0
> -
>
> Key: SOLR-14583
> URL: https://issues.apache.org/jira/browse/SOLR-14583
> Project: Solr
> Issue Type: Bug
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-14583.patch, SOLR-14583.patch
>
>
> SOLR-4280 added to support fractional support for
> spellcheck.maxResultsForSuggest. After SOLR-4280,
> {{spellcheck.maxResultsForSuggest=0}} is treated same as not specify the
> {{spellcheck.maxResultsForSuggest}} parameter. This can cause spell
> suggestions to be returned even when hits are non-zero and greater than
> {{spellcheck.maxResultsForSuggest}} (i.e, greater than 0)
--
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-14669) Solr 8.6 / ZK 3.6.1 / Admin UI - ZK Status Null
[ https://issues.apache.org/jira/browse/SOLR-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Franke updated SOLR-14669: --- Description: When opening the Admin UI / ZK Status page it shows just null. Solr 8.6.0 / ZK 3.6.1. Zk is a 3 node ensemble. It seems to be cosmetic in the UI - otherwise Solr seems to work fine. Deleted already browser cache and restarted browser. Issue persists. In the logfiles I find the following error: 2020-07-20 16:34:27.853 ERROR (qtp767511741-2227) [ ] o.a.s.h.RequestHandlerBase java.lang.NumberFormatException: For input string: "null" at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.base/java.lang.Integer.parseInt(Integer.java:652) at java.base/java.lang.Integer.parseInt(Integer.java:770) at org.apache.solr.handler.admin.ZookeeperStatusHandler.getZkStatus(ZookeeperStatusHandler.java:116) at org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:78) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211) at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:839) at org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:805) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:558) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:419) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:505) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427) at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321) at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917) at java.base/java.lang.Thread.run(Thread.java:834) 2020-07-20 16:34:2
[jira] [Updated] (SOLR-14669) Solr 8.6 / ZK 3.6.1 / Admin UI - ZK Status Null
[ https://issues.apache.org/jira/browse/SOLR-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Franke updated SOLR-14669: --- Description: When opening the Admin UI / ZK Status page it shows just null. Solr 8.6.0 / ZK 3.6.1 It seems to be cosmetic in the UI - otherwise Solr seems to work fine. Deleted already browser cache and restarted browser. Issue persists. In the logfiles I find the following error: 2020-07-20 16:34:27.853 ERROR (qtp767511741-2227) [ ] o.a.s.h.RequestHandlerBase java.lang.NumberFormatException: For input string: "null" at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.base/java.lang.Integer.parseInt(Integer.java:652) at java.base/java.lang.Integer.parseInt(Integer.java:770) at org.apache.solr.handler.admin.ZookeeperStatusHandler.getZkStatus(ZookeeperStatusHandler.java:116) at org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:78) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211) at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:839) at org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:805) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:558) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:419) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:505) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427) at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321) at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917) at java.base/java.lang.Thread.run(Thread.java:834) 2020-07-20 16:34:27.853 INFO (qtp767511741-
[jira] [Updated] (SOLR-14669) Solr 8.6 / ZK 3.6.1 / Admin UI - ZK Status Null
[ https://issues.apache.org/jira/browse/SOLR-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörn Franke updated SOLR-14669: --- Component/s: SolrCloud Admin UI Affects Version/s: 8.6 Description: When opening the Admin UI / ZK Status page it shows just null. Solr 8.6.0 / ZK 3.6.1 It seems to be cosmetic in the UI - otherwise Solr seems to work fine. In the logfiles I find the following error: 2020-07-20 16:34:27.853 ERROR (qtp767511741-2227) [ ] o.a.s.h.RequestHandlerBase java.lang.NumberFormatException: For input string: "null" at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.base/java.lang.Integer.parseInt(Integer.java:652) at java.base/java.lang.Integer.parseInt(Integer.java:770) at org.apache.solr.handler.admin.ZookeeperStatusHandler.getZkStatus(ZookeeperStatusHandler.java:116) at org.apache.solr.handler.admin.ZookeeperStatusHandler.handleRequestBody(ZookeeperStatusHandler.java:78) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:211) at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:839) at org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:805) at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:558) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:419) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:351) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1602) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:540) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1711) at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1347) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:480) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1678) at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1249) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:220) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:152) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:335) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) at org.eclipse.jetty.server.Server.handle(Server.java:505) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:370) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:267) at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:305) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.onFillable(SslConnection.java:427) at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:321) at org.eclipse.jetty.io.ssl.SslConnection$2.succeeded(SslConnection.java:159) at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781) at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917) at java.base/java.lang.Thread.run(Thread.java:834) 2020-07-20 16:34:2
[jira] [Created] (SOLR-14669) Solr 8.6 / ZK 3.6.1 / Admin UI -
Jörn Franke created SOLR-14669: -- Summary: Solr 8.6 / ZK 3.6.1 / Admin UI - Key: SOLR-14669 URL: https://issues.apache.org/jira/browse/SOLR-14669 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Reporter: Jörn Franke -- 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-14435) createNodeSet and createNodeSet.shuffle parameters missing from Collection Restore RefGuide
[
https://issues.apache.org/jira/browse/SOLR-14435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161374#comment-17161374
]
David Eric Pugh commented on SOLR-14435:
[~asalamon74] Looking at master, maxShardsPerNode just disppeared ;-)
I think what you are suggesting is that the sentence "Additionally, there are
several parameters that may have been set" under RESTORE could be changed to
just list all the parameters, pointing to CREATE, similar to what we did with
createNodeSet and createNodeSet.shuffle right?
> createNodeSet and createNodeSet.shuffle parameters missing from Collection
> Restore RefGuide
> ---
>
> Key: SOLR-14435
> URL: https://issues.apache.org/jira/browse/SOLR-14435
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Reporter: Andras Salamon
>Assignee: David Eric Pugh
>Priority: Minor
> Attachments: SOLR-14435-01.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Although {{createNodeSet}} and {{createNodeSet.shuffle}} parameters are
> supported by the Collection RESTORE command (I've tested it), they are
> missing from the documentation:
> [https://lucene.apache.org/solr/guide/8_5/collection-management.html#collection-management]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161362#comment-17161362 ] ASF subversion and git services commented on LUCENE-9312: - Commit c43188d0282082c77f70f9a219f34a4e45118b4b in lucene-solr's branch refs/heads/jira/LUCENE-9312 from Tomoko Uchida [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=c43188d ] LUCENE-9312: evaluate 'javadocCmdPath' property in task definition > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14583) Spell suggestion is returned even if hits are non-zero when spellcheck.maxResultsForSuggest=0
[
https://issues.apache.org/jira/browse/SOLR-14583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161361#comment-17161361
]
James Dyer commented on SOLR-14583:
---
[~munendrasn] Taking a quick look at the test changes in your last patch, I
surmise you are finding it does not work correctly when extended results are
turned off? Or, can you describe the problem in detail?
I think the reason we do not expose the suggest mode directly is that it
decides which one to use mid-query. That is, if the results come back and it is
less than "alternativeTermCount", it uses "suggest always" otherwise it uses
"suggest when not in index". Perhaps my memory on this is too faded.
In any case, we probably shouldn't make breaking API changes unless we can
demonstrate a clear benefit to the user. I do agree the current spellcheck is
difficult for users to configure.
> Spell suggestion is returned even if hits are non-zero when
> spellcheck.maxResultsForSuggest=0
> -
>
> Key: SOLR-14583
> URL: https://issues.apache.org/jira/browse/SOLR-14583
> Project: Solr
> Issue Type: Bug
>Reporter: Munendra S N
>Assignee: Munendra S N
>Priority: Major
> Attachments: SOLR-14583.patch, SOLR-14583.patch
>
>
> SOLR-4280 added to support fractional support for
> spellcheck.maxResultsForSuggest. After SOLR-4280,
> {{spellcheck.maxResultsForSuggest=0}} is treated same as not specify the
> {{spellcheck.maxResultsForSuggest}} parameter. This can cause spell
> suggestions to be returned even when hits are non-zero and greater than
> {{spellcheck.maxResultsForSuggest}} (i.e, greater than 0)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161317#comment-17161317
]
Mark Robert Miller edited comment on SOLR-14636 at 7/20/20, 3:23 PM:
-
https://asciinema.org/a/UihzjUi6xL4M2U0w749wEcI42?speed=2
was (Author: markrmiller):
https://asciinema.org/a/UihzjUi6xL4M2U0w749wEcI42
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> {color:#de350b}NOTE: Just entered a period of likely instability as I clear
> out the new room of zombies.{color}
> *tests***:
> * *core*: {color:#00875a}*solid*{color} with *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*solid*{color} with {color:#de350b}*ignores*{color}
> * *test-framework*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
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-14435) createNodeSet and createNodeSet.shuffle parameters missing from Collection Restore RefGuide
[
https://issues.apache.org/jira/browse/SOLR-14435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161318#comment-17161318
]
Andras Salamon commented on SOLR-14435:
---
The {{async}} parameter already duplicated in CREATE and RESTORE documentation.
(But it's a very short sentence).
I think all the override parameters in RESTORE are also available in CREATE
(that's why we can override them). It seems to me this section was block-copied
earlier, the documentation of RESTORE/maxShardsPerNode refers to the CREATE
action instead of the RESTORE action. Maybe this section can be eliminated and
listing these parameters would be enough.
> createNodeSet and createNodeSet.shuffle parameters missing from Collection
> Restore RefGuide
> ---
>
> Key: SOLR-14435
> URL: https://issues.apache.org/jira/browse/SOLR-14435
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Reporter: Andras Salamon
>Assignee: David Eric Pugh
>Priority: Minor
> Attachments: SOLR-14435-01.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Although {{createNodeSet}} and {{createNodeSet.shuffle}} parameters are
> supported by the Collection RESTORE command (I've tested it), they are
> missing from the documentation:
> [https://lucene.apache.org/solr/guide/8_5/collection-management.html#collection-management]
--
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-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161317#comment-17161317
]
Mark Robert Miller commented on SOLR-14636:
---
https://asciinema.org/a/UihzjUi6xL4M2U0w749wEcI42
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> {color:#de350b}NOTE: Just entered a period of likely instability as I clear
> out the new room of zombies.{color}
> *tests***:
> * *core*: {color:#00875a}*solid*{color} with *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*solid*{color} with {color:#de350b}*ignores*{color}
> * *test-framework*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
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-14435) createNodeSet and createNodeSet.shuffle parameters missing from Collection Restore RefGuide
[
https://issues.apache.org/jira/browse/SOLR-14435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161283#comment-17161283
]
David Eric Pugh commented on SOLR-14435:
Hey [~asalamon74]and [~ctargett]how does this PR look?
https://github.com/apache/lucene-solr/pull/1683
[~asalamon74]are there any other parameters we should be including in the list?
Thanks for raising this issue.
> createNodeSet and createNodeSet.shuffle parameters missing from Collection
> Restore RefGuide
> ---
>
> Key: SOLR-14435
> URL: https://issues.apache.org/jira/browse/SOLR-14435
> Project: Solr
> Issue Type: Improvement
> Components: documentation
>Reporter: Andras Salamon
>Assignee: David Eric Pugh
>Priority: Minor
> Attachments: SOLR-14435-01.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Although {{createNodeSet}} and {{createNodeSet.shuffle}} parameters are
> supported by the Collection RESTORE command (I've tested it), they are
> missing from the documentation:
> [https://lucene.apache.org/solr/guide/8_5/collection-management.html#collection-management]
--
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] epugh opened a new pull request #1683: SOLR-14435
epugh opened a new pull request #1683: URL: https://github.com/apache/lucene-solr/pull/1683 # Description document missing parameters # Solution Refguide fix 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-9433) Remove Ant support from trunk
[
https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161277#comment-17161277
]
Dawid Weiss commented on LUCENE-9433:
-
bq. I never run the 'documentation' task, so my only wish would be that there's
still a command ('buildSite' or we can rename it to 'refGuide', or whatever)
that only builds the Ref Guide.
Remember tasks work per-project. So you could do this to apply 'documentation'
task to just the ref guide:
gradlew -p solr/solr-ref-guide documentation
and it wouldn't do anything else.
> Remove Ant support from trunk
> -
>
> Key: LUCENE-9433
> URL: https://issues.apache.org/jira/browse/LUCENE-9433
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Items that may need to be addressed:
> * Testing with OpenJDK early access releases
> * Mavenizing
> * Test speed (?)
> * Update any mentions of ant in the ref guide
> * Update Confluence, in particular "how to contribute"
> * Update Jenkins to not try to run ant anything
> * make an eclipse task
> * various documentation (e.g. README/INSTALL) files still needs to be
> converted to gradle
> * fix some relative links in javadocs which contain ant module names
--
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-13205) StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
[
https://issues.apache.org/jira/browse/SOLR-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161267#comment-17161267
]
Jason Gerlowski commented on SOLR-13205:
Thanks for the contribution Pramod. Congrats on your first commit!
I've merged this to master which means it'll be in 9.0 for sure. I also plan
on merging to branch_8x so that this will be in 8.7, but want to keep an eye on
test runs for a few days first - make sure nothing shakes out that worked
locally but fails in other situations. I'll close this out when I merge then.
> StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
>
>
> Key: SOLR-13205
> URL: https://issues.apache.org/jira/browse/SOLR-13205
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection and reproducing the bug
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html].
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will
> allow you to reproduce the issue reported.
>Reporter: Johannes Kloos
>Assignee: Jason Gerlowski
>Priority: Minor
> Labels: diffblue, newdev
> Attachments: SOLR-13205.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?df=&explainOther=debug=all&debugQuery=on
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:658)
> at
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:1045)
> at
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:801)
> at org.apache.solr.parser.QueryParser.Term(QueryParser.java:421)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:278)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:255)
> at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)
> at org.apache.solr.search.QParser.getQuery(QParser.java:173)
> at
> org.apache.solr.util.SolrPluginUtils.doSimpleQuery(SolrPluginUtils.java:479)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardResultsDebug(SolrPluginUtils.java:390)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardDebug(SolrPluginUtils.java:343)
> at
> org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:100)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:306)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> {noformat}
> The “df” parameter means that we set the empty string as default field(!).
> Since we do not give a field in the query, the default field is substituted
> in getFieldQuery. We then check if the field starts with “_” by using
> charAt(0).
> A trivial fix would be to replace field.charAt(0) == ‘_’ with
> field.startsWith(“_”).
> To set up an environment to reproduce this bug, follow the descripti
[jira] [Commented] (SOLR-13205) StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
[
https://issues.apache.org/jira/browse/SOLR-13205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161264#comment-17161264
]
ASF subversion and git services commented on SOLR-13205:
Commit 48e92ba9c74ebf204308793d9a00bc48b2780136 in lucene-solr's branch
refs/heads/master from Jason Gerlowski
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=48e92ba ]
SOLR-13205: Improve empty-string handling in SolrQueryParserBase
Contributed-By: pramodkumar9
> StringIndexOutOfBoundsException in SolrQueryParserBase.getFieldQuery
>
>
> Key: SOLR-13205
> URL: https://issues.apache.org/jira/browse/SOLR-13205
> Project: Solr
> Issue Type: Bug
> Components: search
>Affects Versions: master (9.0)
> Environment: h1. Steps to reproduce
> * Use a Linux machine.
> * Build commit {{ea2c8ba}} of Solr as described in the section below.
> * Build the films collection as described below.
> * Start the server using the command {{./bin/solr start -f -p 8983 -s
> /tmp/home}}
> * Request the URL given in the bug description.
> h1. Compiling the server
> {noformat}
> git clone https://github.com/apache/lucene-solr
> cd lucene-solr
> git checkout ea2c8ba
> ant compile
> cd solr
> ant server
> {noformat}
> h1. Building the collection and reproducing the bug
> We followed [Exercise
> 2|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html#exercise-2] from
> the [Solr
> Tutorial|http://lucene.apache.org/solr/guide/7_5/solr-tutorial.html].
> {noformat}
> mkdir -p /tmp/home
> echo '' >
> /tmp/home/solr.xml
> {noformat}
> In one terminal start a Solr instance in foreground:
> {noformat}
> ./bin/solr start -f -p 8983 -s /tmp/home
> {noformat}
> In another terminal, create a collection of movies, with no shards and no
> replication, and initialize it:
> {noformat}
> bin/solr create -c films
> curl -X POST -H 'Content-type:application/json' --data-binary '{"add-field":
> {"name":"name", "type":"text_general", "multiValued":false, "stored":true}}'
> http://localhost:8983/solr/films/schema
> curl -X POST -H 'Content-type:application/json' --data-binary
> '{"add-copy-field" : {"source":"*","dest":"_text_"}}'
> http://localhost:8983/solr/films/schema
> ./bin/post -c films example/films/films.json
> curl -v “URL_BUG”
> {noformat}
> Please check the issue description below to find the “URL_BUG” that will
> allow you to reproduce the issue reported.
>Reporter: Johannes Kloos
>Assignee: Jason Gerlowski
>Priority: Minor
> Labels: diffblue, newdev
> Attachments: SOLR-13205.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Requesting the following URL causes Solr to return an HTTP 500 error response:
> {noformat}
> http://localhost:8983/solr/films/select?df=&explainOther=debug=all&debugQuery=on
> {noformat}
> The error response seems to be caused by the following uncaught exception:
> {noformat}
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.String.charAt(String.java:658)
> at
> org.apache.solr.parser.SolrQueryParserBase.getFieldQuery(SolrQueryParserBase.java:1045)
> at
> org.apache.solr.parser.SolrQueryParserBase.handleBareTokenQuery(SolrQueryParserBase.java:801)
> at org.apache.solr.parser.QueryParser.Term(QueryParser.java:421)
> at org.apache.solr.parser.QueryParser.Clause(QueryParser.java:278)
> at org.apache.solr.parser.QueryParser.Query(QueryParser.java:162)
> at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:131)
> at
> org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:255)
> at org.apache.solr.search.LuceneQParser.parse(LuceneQParser.java:49)
> at org.apache.solr.search.QParser.getQuery(QParser.java:173)
> at
> org.apache.solr.util.SolrPluginUtils.doSimpleQuery(SolrPluginUtils.java:479)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardResultsDebug(SolrPluginUtils.java:390)
> at
> org.apache.solr.util.SolrPluginUtils.doStandardDebug(SolrPluginUtils.java:343)
> at
> org.apache.solr.handler.component.DebugComponent.process(DebugComponent.java:100)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:306)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:199)
> {noformat}
> The “df” parameter means that we set the empty string as default field(!).
> Since we do not give a field in the query, the default field is substituted
> in getFieldQuery. We then check if the field starts with “_” by using
> charAt(0).
> A trivial fix would be to replace field.charAt(0) == ‘_’ with
> field.startsWith(“_”).
> To set up an environment to reproduce this bug, follow the description in the
> ‘Environment’ field.
> We automatically found this issue and
[jira] [Commented] (SOLR-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161242#comment-17161242
]
Ilan Ginzburg commented on SOLR-14636:
--
[~markrmiller] the Overseer trigger thread on master is gone as from a few
minutes ago, as is the complete Autoscaling code. Also (post June 8 when you
took the snapshot of the branch) we've removed {{/clusterstate.json}} and the
logic related to legacy cloud and state format 1 collections.
Should make your life easier but rebase a bit harder...
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> {color:#de350b}NOTE: Just entered a period of likely instability as I clear
> out the new room of zombies.{color}
> *tests***:
> * *core*: {color:#00875a}*solid*{color} with *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*solid*{color} with {color:#de350b}*ignores*{color}
> * *test-framework*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9433) Remove Ant support from trunk
[
https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161243#comment-17161243
]
Cassandra Targett commented on LUCENE-9433:
---
bq. The build.gradle file you pointed out actually excludes those files from
the classpath, so I think it's OK to remove them, at least I don't think
removing them breaks the exclusion.
Ah, yeah, OK then remove them. If you got the Ref Guide build to complete
successfully, then removing them is fine.
bq. Maybe we could attach it to 'documentation' task... I recall my concern was
that it took
a while to compile but if somebody wants to run 'documentation' on a top-level
for
every project then this would be an acceptable tradeoff... This also can be
done later.
Agree it can be done later. I never run the 'documentation' task, so my only
wish would be that there's still a command ('buildSite' or we can rename it to
'refGuide', or whatever) that only builds the Ref Guide. Whether it's also part
of other tasks doesn't matter to my current workflow, so whatever folks want to
do would be fine with me.
> Remove Ant support from trunk
> -
>
> Key: LUCENE-9433
> URL: https://issues.apache.org/jira/browse/LUCENE-9433
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Items that may need to be addressed:
> * Testing with OpenJDK early access releases
> * Mavenizing
> * Test speed (?)
> * Update any mentions of ant in the ref guide
> * Update Confluence, in particular "how to contribute"
> * Update Jenkins to not try to run ant anything
> * make an eclipse task
> * various documentation (e.g. README/INSTALL) files still needs to be
> converted to gradle
> * fix some relative links in javadocs which contain ant module names
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-9433) Remove Ant support from trunk
[
https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161243#comment-17161243
]
Cassandra Targett edited comment on LUCENE-9433 at 7/20/20, 1:29 PM:
-
bq. The build.gradle file you pointed out actually excludes those files from
the classpath, so I think it's OK to remove them, at least I don't think
removing them breaks the exclusion.
Ah, yeah, OK then remove them. If you got the Ref Guide build to complete
successfully, then removing them is fine.
bq. Maybe we could attach it to 'documentation' task... I recall my concern was
that it took a while to compile but if somebody wants to run 'documentation' on
a top-level for every project then this would be an acceptable tradeoff... This
also can be done later.
Agree it can be done later. I never run the 'documentation' task, so my only
wish would be that there's still a command ('buildSite' or we can rename it to
'refGuide', or whatever) that only builds the Ref Guide. Whether it's also part
of other tasks doesn't matter to my current workflow, so whatever folks want to
do would be fine with me.
was (Author: ctargett):
bq. The build.gradle file you pointed out actually excludes those files from
the classpath, so I think it's OK to remove them, at least I don't think
removing them breaks the exclusion.
Ah, yeah, OK then remove them. If you got the Ref Guide build to complete
successfully, then removing them is fine.
bq. Maybe we could attach it to 'documentation' task... I recall my concern was
that it took
a while to compile but if somebody wants to run 'documentation' on a top-level
for
every project then this would be an acceptable tradeoff... This also can be
done later.
Agree it can be done later. I never run the 'documentation' task, so my only
wish would be that there's still a command ('buildSite' or we can rename it to
'refGuide', or whatever) that only builds the Ref Guide. Whether it's also part
of other tasks doesn't matter to my current workflow, so whatever folks want to
do would be fine with me.
> Remove Ant support from trunk
> -
>
> Key: LUCENE-9433
> URL: https://issues.apache.org/jira/browse/LUCENE-9433
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Items that may need to be addressed:
> * Testing with OpenJDK early access releases
> * Mavenizing
> * Test speed (?)
> * Update any mentions of ant in the ref guide
> * Update Confluence, in particular "how to contribute"
> * Update Jenkins to not try to run ant anything
> * make an eclipse task
> * various documentation (e.g. README/INSTALL) files still needs to be
> converted to gradle
> * fix some relative links in javadocs which contain ant module names
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161236#comment-17161236
]
Tomoko Uchida commented on LUCENE-9312:
---
{quote}We could have a global JVM setting... but I don't think it really
changes that much. If we switch to Java X + 1 then it's fairly simple to look
up those affected bits (javac, javadoc). Sometimes explicit is simpler, even if
it's duplication.
{quote}
I have no strong feeling about that; we should never forget javadoc stuff some
years later :)
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14656) Deprecate current autoscaling framework, remove from master
[ https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161233#comment-17161233 ] Ishan Chattopadhyaya commented on SOLR-14656: - Thanks [~ctargett], fixed. > Deprecate current autoscaling framework, remove from master > --- > > Key: SOLR-14656 > URL: https://issues.apache.org/jira/browse/SOLR-14656 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: Screenshot from 2020-07-18 07-49-01.png > > Time Spent: 3h > Remaining Estimate: 0h > > The autoscaling framework is being re-designed in SOLR-14613 (SIP: > https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2). > The current autoscaling framework is very inefficient, improperly designed > and too bloated and doesn't receive the level of support we aspire to provide > for all components that we ship. > This issue is to deprecate current autoscaling framework in 8x, so we can > focus on the new autoscaling framework afresh. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14656) Deprecate current autoscaling framework, remove from master
[ https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161190#comment-17161190 ] Ishan Chattopadhyaya edited comment on SOLR-14656 at 7/20/20, 1:22 PM: --- Removal is done! [~ilan], you have a clean slate to design the future of this feature. This is an exciting moment! [~ab], would you like to tackle the deprecation in 8x? I didn't go for it, since I think I read that you have plans to address performance issues in the 8x branch. Another reason was that I wasn't fully familiar with all the touchpoints of the framework. was (Author: ichattopadhyaya): Removal is done! [~ilan], you have a clean slate to design the future of this feature. This is an exciting moment! [~ab], would you like to tackle the deprecation in 8x? I didn't go for it, since I think I read that you have plans to address performance issues in the 8x branch. > Deprecate current autoscaling framework, remove from master > --- > > Key: SOLR-14656 > URL: https://issues.apache.org/jira/browse/SOLR-14656 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: Screenshot from 2020-07-18 07-49-01.png > > Time Spent: 3h > Remaining Estimate: 0h > > The autoscaling framework is being re-designed in SOLR-14613 (SIP: > https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2). > The current autoscaling framework is very inefficient, improperly designed > and too bloated and doesn't receive the level of support we aspire to provide > for all components that we ship. > This issue is to deprecate current autoscaling framework in 8x, so we can > focus on the new autoscaling framework afresh. -- 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-14656) Deprecate current autoscaling framework, remove from master
[ https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161232#comment-17161232 ] ASF subversion and git services commented on SOLR-14656: Commit b46321e19e2bea1981c5a22a9db4d9236a06f146 in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=b46321e ] SOLR-14656: Adding back REPLACENODE documentation that was omitted by mistake > Deprecate current autoscaling framework, remove from master > --- > > Key: SOLR-14656 > URL: https://issues.apache.org/jira/browse/SOLR-14656 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: Screenshot from 2020-07-18 07-49-01.png > > Time Spent: 3h > Remaining Estimate: 0h > > The autoscaling framework is being re-designed in SOLR-14613 (SIP: > https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2). > The current autoscaling framework is very inefficient, improperly designed > and too bloated and doesn't receive the level of support we aspire to provide > for all components that we ship. > This issue is to deprecate current autoscaling framework in 8x, so we can > focus on the new autoscaling framework afresh. -- 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-14636) Provide a reference implementation for SolrCloud that is stable and fast.
[
https://issues.apache.org/jira/browse/SOLR-14636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161225#comment-17161225
]
Mark Robert Miller commented on SOLR-14636:
---
So the Overseer autoscaling trigger thread is disabled. I had forgotten about
him. I've done 2 iterations of this since putting him on my hit list and had
completely forgotten he was even on it. He defies improvement more than others
and that time and this, he/she does not seem worth the effort to keep wrangling
at this time.
> Provide a reference implementation for SolrCloud that is stable and fast.
> -
>
> Key: SOLR-14636
> URL: https://issues.apache.org/jira/browse/SOLR-14636
> Project: Solr
> Issue Type: Task
>Reporter: Mark Robert Miller
>Assignee: Mark Robert Miller
>Priority: Major
> Attachments: IMG_5575 (1).jpg
>
>
> SolrCloud powers critical infrastructure and needs the ability to run quickly
> with stability. This reference implementation will allow for this.
> *location*: [https://github.com/apache/lucene-solr/tree/reference_impl]
> *status*: alpha
> *speed*: ludicrous
> {color:#de350b}NOTE: Just entered a period of likely instability as I clear
> out the new room of zombies.{color}
> *tests***:
> * *core*: {color:#00875a}*solid*{color} with *{color:#de350b}ignores{color}*
> * *solrj*: {color:#00875a}*solid*{color} with {color:#de350b}*ignores*{color}
> * *test-framework*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analysis-extras*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/analytics*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/clustering*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/dataimporthandler*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/dataimporthandler-extras*: {color:#00875a}*solid*{color} with
> *{color:#de350b}ignores{color}*
> * *contrib/extraction*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/jaegertracer-configurator*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/langid*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/prometheus-exporter*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> * *contrib/velocity*: {color:#00875a}*solid*{color} with
> {color:#de350b}*ignores*{color}
> _* Running tests quickly and efficiently with strict policing will more
> frequently find bugs and requires a period of hardening._
> _** Non Nightly currently, Nightly comes last._
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161223#comment-17161223
]
Tomoko Uchida commented on LUCENE-9312:
---
[~dweiss] I pushed the change for {{renderJavadoc}} and {{renderSiteJavadoc (by
following your comment in the gradle file, thank you).}}
It works for me as below (for debugging, I just added the javadoc command path
to be called to the output file):
{code:java}
lucene-solr$ ./gradlew
-Druntime.java.home=/Users/tomoko.uchida/.sdkman/candidates/java/14.0.1.hs-adpt
-p lucene/analysis/kuromoji javadoc
> Task :altJvmWarning
NOTE: Alternative java toolchain will be used for compilation and tests:
Project will use Java 14 from:
/Users/tomoko.uchida/.sdkman/candidates/java/14.0.1.hs-adpt
Gradle runs with Java 11 from:
/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
...
BUILD SUCCESSFUL in 32s
8 actionable tasks: 8 executed
lucene-solr$ cat
lucene/analysis/kuromoji/build/tmp/renderJavadoc/javadoc-output.txt
Javadoc command path:
/Users/tomoko.uchida/.sdkman/candidates/java/14.0.1.hs-adpt/bin/javadoc
{code}
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14656) Deprecate current autoscaling framework, remove from master
[
https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161219#comment-17161219
]
Cassandra Targett edited comment on SOLR-14656 at 7/20/20, 1:09 PM:
In the process of removing documentation for UTILIZENODE, the command after it
in {{cluster-node-management.adoc}}, REPLACENODE, was also partially removed,
leaving the section "REPLACENODE Parameters" but not the introductory text that
explains it. Is REPLACENODE also removed with this commit? If not, please add
the removed beginning of the section back. If it is intended to be removed,
please properly clean up the remaining documentation for that command.
was (Author: ctargett):
In the process of removing documentation for UTILIZENODE, the command after it
in {{cluster-node-management.adoc}}, REPLACENODE, was also partially removed,
leaving the section "REPLACENODE Parameters". Is REPLACENODE also removed with
this commit? If not, please add the removed beginning of the section back. If
it is intended to be removed, please properly clean up the remaining
documentation for that command.
> Deprecate current autoscaling framework, remove from master
> ---
>
> Key: SOLR-14656
> URL: https://issues.apache.org/jira/browse/SOLR-14656
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: Screenshot from 2020-07-18 07-49-01.png
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> The autoscaling framework is being re-designed in SOLR-14613 (SIP:
> https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2).
> The current autoscaling framework is very inefficient, improperly designed
> and too bloated and doesn't receive the level of support we aspire to provide
> for all components that we ship.
> This issue is to deprecate current autoscaling framework in 8x, so we can
> focus on the new autoscaling framework afresh.
--
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-9433) Remove Ant support from trunk
[ https://issues.apache.org/jira/browse/LUCENE-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated LUCENE-9433: --- Description: Items that may need to be addressed: * Testing with OpenJDK early access releases * Mavenizing * Test speed (?) * Update any mentions of ant in the ref guide * Update Confluence, in particular "how to contribute" * Update Jenkins to not try to run ant anything * make an eclipse task * various documentation (e.g. README/INSTALL) files still needs to be converted to gradle * fix some relative links in javadocs which contain ant module names was: Items that may need to be addressed: * Testing with OpenJDK early access releases * Mavenizing * Test speed (?) * check build for ref guide * Update Confluence * Update Jenkins to not try to run ant anything * make an eclipse task * various documentation (e.g. README/INSTALL) files still needs to be converted to gradle * fix some relative links in javadocs which contain ant module names > Remove Ant support from trunk > - > > Key: LUCENE-9433 > URL: https://issues.apache.org/jira/browse/LUCENE-9433 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Items that may need to be addressed: > * Testing with OpenJDK early access releases > * Mavenizing > * Test speed (?) > * Update any mentions of ant in the ref guide > * Update Confluence, in particular "how to contribute" > * Update Jenkins to not try to run ant anything > * make an eclipse task > * various documentation (e.g. README/INSTALL) files still needs to be > converted to gradle > * fix some relative links in javadocs which contain ant module names -- 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-14656) Deprecate current autoscaling framework, remove from master
[
https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161219#comment-17161219
]
Cassandra Targett commented on SOLR-14656:
--
In the process of removing documentation for UTILIZENODE, the command after it
in {{cluster-node-management.adoc}}, REPLACENODE, was also partially removed,
leaving the section "REPLACENODE Parameters". Is REPLACENODE also removed with
this commit? If not, please add the removed beginning of the section back. If
it is intended to be removed, please properly clean up the remaining
documentation for that command.
> Deprecate current autoscaling framework, remove from master
> ---
>
> Key: SOLR-14656
> URL: https://issues.apache.org/jira/browse/SOLR-14656
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Ishan Chattopadhyaya
>Priority: Major
> Attachments: Screenshot from 2020-07-18 07-49-01.png
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> The autoscaling framework is being re-designed in SOLR-14613 (SIP:
> https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2).
> The current autoscaling framework is very inefficient, improperly designed
> and too bloated and doesn't receive the level of support we aspire to provide
> for all components that we ship.
> This issue is to deprecate current autoscaling framework in 8x, so we can
> focus on the new autoscaling framework afresh.
--
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-14613) Provide a clean API for pluggable autoscaling implementations
[
https://issues.apache.org/jira/browse/SOLR-14613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161217#comment-17161217
]
Erick Erickson commented on SOLR-14613:
---
{quote}using a strongly typed approach
{quote}
I'm so glad to hear you say that ;)
> Provide a clean API for pluggable autoscaling implementations
> -
>
> Key: SOLR-14613
> URL: https://issues.apache.org/jira/browse/SOLR-14613
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
>Reporter: Andrzej Bialecki
>Priority: Major
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> As described in SIP-8 the current autoscaling Policy implementation has
> several limitations that make it difficult to use for very large clusters and
> very large collections. SIP-8 also mentions the possible migration path by
> providing alternative implementations of the placement strategies that are
> less complex but more efficient in these very large environments.
> We should review the existing APIs that the current autoscaling engine uses
> ({{SolrCloudManager}} , {{AssignStrategy}} , {{Suggester}} and related
> interfaces) to see if they provide a sufficient and minimal API for plugging
> in alternative autoscaling placement strategies, and if necessary refactor
> the existing APIs.
> Since these APIs are internal it should be possible to do this without
> breaking back-compat.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161215#comment-17161215 ] ASF subversion and git services commented on LUCENE-9312: - Commit 964dad20de4fcafa44c50cc282b60b698b767489 in lucene-solr's branch refs/heads/jira/LUCENE-9312 from Tomoko Uchida [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=964dad2 ] LUCENE-9312: set proper javadoc executable path (if Java runtime is specified). > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14656) Deprecate current autoscaling framework, remove from master
[ https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161190#comment-17161190 ] Ishan Chattopadhyaya commented on SOLR-14656: - Removal is done! [~ilan], you have a clean slate to design the future of this feature. This is an exciting moment! [~ab], would you like to tackle the deprecation in 8x? I didn't go for it, since I think I read that you have plans to address performance issues in the 8x branch. > Deprecate current autoscaling framework, remove from master > --- > > Key: SOLR-14656 > URL: https://issues.apache.org/jira/browse/SOLR-14656 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: Screenshot from 2020-07-18 07-49-01.png > > Time Spent: 3h > Remaining Estimate: 0h > > The autoscaling framework is being re-designed in SOLR-14613 (SIP: > https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2). > The current autoscaling framework is very inefficient, improperly designed > and too bloated and doesn't receive the level of support we aspire to provide > for all components that we ship. > This issue is to deprecate current autoscaling framework in 8x, so we can > focus on the new autoscaling framework afresh. -- 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] chatman closed pull request #1679: SOLR-14656: Removing autoscaling from master
chatman closed pull request #1679: URL: https://github.com/apache/lucene-solr/pull/1679 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] chatman commented on pull request #1679: SOLR-14656: Removing autoscaling from master
chatman commented on pull request #1679: URL: https://github.com/apache/lucene-solr/pull/1679#issuecomment-660992518 Merged, thanks @noblepaul @murblanc. AFAIK, all traces of autoscaling have been removed. However, if there's something still left over, we can remove them in another PR. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14656) Deprecate current autoscaling framework, remove from master
[ https://issues.apache.org/jira/browse/SOLR-14656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161187#comment-17161187 ] ASF subversion and git services commented on SOLR-14656: Commit cc0c111949d5039a0c7cb67cad55c63e2f761298 in lucene-solr's branch refs/heads/master from Ishan Chattopadhyaya [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=cc0c111 ] SOLR-14656: Removing Autoscaling Framework The following were removed: * Autoscaling policy, triggers etc. * withCollection handling * UTILIZENODE command * Sim framework * Suggestions tab in UI * Reference guide pages for autoscaling * autoAddReplicas feature * UTILIZENODE > Deprecate current autoscaling framework, remove from master > --- > > Key: SOLR-14656 > URL: https://issues.apache.org/jira/browse/SOLR-14656 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Ishan Chattopadhyaya >Priority: Major > Attachments: Screenshot from 2020-07-18 07-49-01.png > > Time Spent: 2h 40m > Remaining Estimate: 0h > > The autoscaling framework is being re-designed in SOLR-14613 (SIP: > https://cwiki.apache.org/confluence/display/SOLR/SIP-8+Autoscaling+policy+engine+V2). > The current autoscaling framework is very inefficient, improperly designed > and too bloated and doesn't receive the level of support we aspire to provide > for all components that we ship. > This issue is to deprecate current autoscaling framework in 8x, so we can > focus on the new autoscaling framework afresh. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris commented on pull request #1682: Use FileSystem.newInstance instead of get in HDFSBackupRepository
atris commented on pull request #1682: URL: https://github.com/apache/lucene-solr/pull/1682#issuecomment-660964937 @mkhludnev Let me know if this looks fine This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] atris opened a new pull request #1682: Use FileSystem.newInstance instead of get in HDFSBackupRepository
atris opened a new pull request #1682: URL: https://github.com/apache/lucene-solr/pull/1682 FileSystem.get can cause FileSystem closed exceptions, especially with S3. Using FileSystem.newInstance should help that case. 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-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161153#comment-17161153 ] Dawid Weiss commented on LUCENE-9312: - We could have a global JVM setting... but I don't think it really changes that much. If we switch to Java X + 1 then it's fairly simple to look up those affected bits (javac, javadoc). Sometimes explicit is simpler, even if it's duplication. Please suggest something if you have something in mind though. > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161152#comment-17161152
]
Tomoko Uchida commented on LUCENE-9312:
---
We have two {{--release 11}} option in defaults-java.gradle and
render-javadoc.gradle. Maybe we can parametrize release target, in other words,
"11" ?
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161149#comment-17161149 ] Dawid Weiss commented on LUCENE-9312: - I have to switch contexts - feel free to fix that javadoc bit (left a todo there, Tomoko) and commit directly to the branch. I'll review later today (or tomorrow) and I think this would wrap up alternative JVM support? > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14523) Enhance gradle logging calls validation: eliminate getMessage()
[
https://issues.apache.org/jira/browse/SOLR-14523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161138#comment-17161138
]
ASF subversion and git services commented on SOLR-14523:
Commit 1d143744bdda80c5e1efc3b6631805d09cd3d7c9 in lucene-solr's branch
refs/heads/master from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1d14374 ]
SOLR-14523: moved logger message to info so that it doesn't pollute console on
regular runs.
> Enhance gradle logging calls validation: eliminate getMessage()
> ---
>
> Key: SOLR-14523
> URL: https://issues.apache.org/jira/browse/SOLR-14523
> Project: Solr
> Issue Type: Improvement
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 8.7
>
> Attachments: SOLR-14523.patch, validation.patch
>
>
> SOLR-14280 fixed a logging problem in SolrConfig by removing a few
> getMessage() calls. We could enhance this solution by modifying gradle's
> logging calls validation and forbid getMessage() calls during logging. We
> should check the existing code and eliminate such calls.
> It is possible to suppress the warning using {{//logok}}.
> [~erickerickson] [~gerlowskija]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9436) Use "release" flag for javac rather than 'source' and 'target' combination
[
https://issues.apache.org/jira/browse/LUCENE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161147#comment-17161147
]
Dawid Weiss commented on LUCENE-9436:
-
Fails with this now -
{code}
> Task :solr:core:compileJava
warning: [path] bad path element
"O:\repos\lucene-master\solr\server\build\classes\java\main": no such file or
directory
error: warnings found and -Werror specified
1 error
1 warning
{code}
These are all follow-up issues, I guess.
> Use "release" flag for javac rather than 'source' and 'target' combination
> --
>
> Key: LUCENE-9436
> URL: https://issues.apache.org/jira/browse/LUCENE-9436
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Trivial
> Fix For: master (9.0)
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161148#comment-17161148
]
Tomoko Uchida commented on LUCENE-9312:
---
ah, it was already committed at {{h=92f6138}} - I've checkout it and it works
for me too.
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161143#comment-17161143
]
Tomoko Uchida commented on LUCENE-9312:
---
FYI this patch works for me. Is it okay to commit to jira/LUCENE-9312 branch?
{code:java}
lucene-solr$ git diff
diff --git a/gradle/defaults-java.gradle b/gradle/defaults-java.gradle
index d9110124389..76a049b68bb 100644
--- a/gradle/defaults-java.gradle
+++ b/gradle/defaults-java.gradle
@@ -25,6 +25,7 @@ allprojects {
tasks.withType(JavaCompile) {
options.encoding = "UTF-8"
options.compilerArgs += [
+"--release", "11",
"-Xlint:-deprecation",
"-Xlint:-serial",
"-Xlint:cast",
{code}
Run {{test}} task:
{code}
lucene-solr$ ./gradlew
-Druntime.java.home=/Users/tomoko.uchida/.sdkman/candidates/java/14.0.1.hs-adpt
-p lucene/analysis/kuromoji test
> Task :altJvmWarning
NOTE: Alternative java toolchain will be used for compilation and tests:
Project will use Java 14 from:
/Users/tomoko.uchida/.sdkman/candidates/java/14.0.1.hs-adpt
Gradle runs with Java 11 from:
/Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
..
> Task :lucene:analysis:kuromoji:test
:lucene:analysis:kuromoji:test (SUCCESS): 159 test(s), 7 skipped
The slowest tests (exceeding 500 ms) during this run:
0.51s TestJapaneseTokenizer.testBocchan (:lucene:analysis:kuromoji)
BUILD SUCCESSFUL in 30s
20 actionable tasks: 10 executed, 10 up-to-date
{code}
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161142#comment-17161142 ] ASF subversion and git services commented on LUCENE-9312: - Commit 92f6138cd271ea262c8bacf7540f62ce7d67aa9b in lucene-solr's branch refs/heads/jira/LUCENE-9312 from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=92f6138 ] Merge branch 'master' into jira/LUCENE-9312 > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (SOLR-14523) Enhance gradle logging calls validation: eliminate getMessage()
[
https://issues.apache.org/jira/browse/SOLR-14523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161141#comment-17161141
]
ASF subversion and git services commented on SOLR-14523:
Commit 1d143744bdda80c5e1efc3b6631805d09cd3d7c9 in lucene-solr's branch
refs/heads/jira/LUCENE-9312 from Dawid Weiss
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=1d14374 ]
SOLR-14523: moved logger message to info so that it doesn't pollute console on
regular runs.
> Enhance gradle logging calls validation: eliminate getMessage()
> ---
>
> Key: SOLR-14523
> URL: https://issues.apache.org/jira/browse/SOLR-14523
> Project: Solr
> Issue Type: Improvement
>Reporter: Andras Salamon
>Assignee: Erick Erickson
>Priority: Minor
> Fix For: 8.7
>
> Attachments: SOLR-14523.patch, validation.patch
>
>
> SOLR-14280 fixed a logging problem in SolrConfig by removing a few
> getMessage() calls. We could enhance this solution by modifying gradle's
> logging calls validation and forbid getMessage() calls during logging. We
> should check the existing code and eliminate such calls.
> It is possible to suppress the warning using {{//logok}}.
> [~erickerickson] [~gerlowskija]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9436) Use "release" flag for javac rather than 'source' and 'target' combination
[ https://issues.apache.org/jira/browse/LUCENE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161140#comment-17161140 ] ASF subversion and git services commented on LUCENE-9436: - Commit f9fff6e1ed189677cd961262546f98f7dda10803 in lucene-solr's branch refs/heads/jira/LUCENE-9312 from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f9fff6e ] LUCENE-9436: use release flag for javac rather than source and target. > Use "release" flag for javac rather than 'source' and 'target' combination > -- > > Key: LUCENE-9436 > URL: https://issues.apache.org/jira/browse/LUCENE-9436 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9436) Use "release" flag for javac rather than 'source' and 'target' combination
[ https://issues.apache.org/jira/browse/LUCENE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161136#comment-17161136 ] Uwe Schindler commented on LUCENE-9436: --- Thanks! I hope the JDK 15 build now works without warning. > Use "release" flag for javac rather than 'source' and 'target' combination > -- > > Key: LUCENE-9436 > URL: https://issues.apache.org/jira/browse/LUCENE-9436 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > -- 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-9436) Use "release" flag for javac rather than 'source' and 'target' combination
[ https://issues.apache.org/jira/browse/LUCENE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-9436. - Resolution: Fixed Done. > Use "release" flag for javac rather than 'source' and 'target' combination > -- > > Key: LUCENE-9436 > URL: https://issues.apache.org/jira/browse/LUCENE-9436 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9436) Use "release" flag for javac rather than 'source' and 'target' combination
[ https://issues.apache.org/jira/browse/LUCENE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161132#comment-17161132 ] ASF subversion and git services commented on LUCENE-9436: - Commit f9fff6e1ed189677cd961262546f98f7dda10803 in lucene-solr's branch refs/heads/master from Dawid Weiss [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=f9fff6e ] LUCENE-9436: use release flag for javac rather than source and target. > Use "release" flag for javac rather than 'source' and 'target' combination > -- > > Key: LUCENE-9436 > URL: https://issues.apache.org/jira/browse/LUCENE-9436 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161130#comment-17161130 ] Uwe Schindler commented on LUCENE-9312: --- bb. I don't know... I bet it is because it's simpler. I just mentioned it because if somebody is paranoid about the toolchain then we should swap out jar as well... I don't care myself (we can remove that TODO if it's a no issue). That's not different to Ant. All tools out there ZIP on their own - forking a process for that makes no sense. We should not change this! I only think that the manifest should refer to the correct version (not sure if the build-jdk is some automatic setting there, I remeber we always had that in the manifest when we used Ant). > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9436) Use "release" flag for javac rather than 'source' and 'target' combination
[ https://issues.apache.org/jira/browse/LUCENE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161116#comment-17161116 ] Dawid Weiss commented on LUCENE-9436: - This seems to be already supported by gradle's JavaCompile task - if it detects release option, it'll suppress source and target. > Use "release" flag for javac rather than 'source' and 'target' combination > -- > > Key: LUCENE-9436 > URL: https://issues.apache.org/jira/browse/LUCENE-9436 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > -- 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-9436) Use "release" flag for javac rather than 'source' and 'target' combination
[ https://issues.apache.org/jira/browse/LUCENE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-9436: Fix Version/s: master (9.0) > Use "release" flag for javac rather than 'source' and 'target' combination > -- > > Key: LUCENE-9436 > URL: https://issues.apache.org/jira/browse/LUCENE-9436 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > Fix For: master (9.0) > > -- 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] (LUCENE-9436) Use "release" flag for javac rather than 'source' and 'target' combination
Dawid Weiss created LUCENE-9436: --- Summary: Use "release" flag for javac rather than 'source' and 'target' combination Key: LUCENE-9436 URL: https://issues.apache.org/jira/browse/LUCENE-9436 Project: Lucene - Core Issue Type: Sub-task Reporter: Dawid Weiss Assignee: Dawid Weiss -- 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-14613) Provide a clean API for pluggable autoscaling implementations
[
https://issues.apache.org/jira/browse/SOLR-14613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161115#comment-17161115
]
Ilan Ginzburg commented on SOLR-14613:
--
My plan in the PR I will share is to define the interfaces and provide sample
plugins implementations showing simple yes somewhat useful placement
implementations. For example random but no 2 replicas of same shard on same
node or something that spreads replicas based on some system property (for
Availability zone approach), or just the current default equal number of cores
per node, highest minimal amount of remaining free disk space.
+I do not plan+ to propose implementations for the interfaces at this stage
(although obviously I'm keeping this need in the back of my mind to propose
realistic interfaces) so we can agree on *what* before we enter the discussion
of *how*...
> Provide a clean API for pluggable autoscaling implementations
> -
>
> Key: SOLR-14613
> URL: https://issues.apache.org/jira/browse/SOLR-14613
> Project: Solr
> Issue Type: Improvement
> Components: AutoScaling
>Reporter: Andrzej Bialecki
>Priority: Major
> Time Spent: 5h 40m
> Remaining Estimate: 0h
>
> As described in SIP-8 the current autoscaling Policy implementation has
> several limitations that make it difficult to use for very large clusters and
> very large collections. SIP-8 also mentions the possible migration path by
> providing alternative implementations of the placement strategies that are
> less complex but more efficient in these very large environments.
> We should review the existing APIs that the current autoscaling engine uses
> ({{SolrCloudManager}} , {{AssignStrategy}} , {{Suggester}} and related
> interfaces) to see if they provide a sufficient and minimal API for plugging
> in alternative autoscaling placement strategies, and if necessary refactor
> the existing APIs.
> Since these APIs are internal it should be possible to do this without
> breaking back-compat.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161112#comment-17161112
]
Dawid Weiss commented on LUCENE-9312:
-
We only pass release - I didn't investigate why jdk 15 issues this warning.
{code}
opts << [ '--release', 11 ]
{code}
bq. Isn't the JAR task not be implemented internall by Gradle as a simple ZIP?
Or do you care about the manifest?
I don't know... I bet it is because it's simpler. I just mentioned it because
if somebody is paranoid about the toolchain then we should swap out jar as
well... I don't care myself (we can remove that TODO if it's a no issue).
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161113#comment-17161113 ] Dawid Weiss commented on LUCENE-9312: - Oh, sorry - was looking at the wrong thing. We pass 'release' from javadoc but gradle's javac does pass source and target so this would have to be fixed (it's a different issue from alt jdk swap though). > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on pull request #1679: SOLR-14656: Removing autoscaling from master
chatman commented on pull request #1679: URL: https://github.com/apache/lucene-solr/pull/1679#issuecomment-660937670 @murblanc I think this is ready for another review. I'm still working on the last piece: removing the suggestions tab in UI. 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-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161105#comment-17161105
]
Uwe Schindler commented on LUCENE-9312:
---
If the issue is not caused by a missing "release" option, use this:
{{\-Xlint:\-options}}
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[GitHub] [lucene-solr] chatman commented on a change in pull request #1679: SOLR-14656: Removing autoscaling from master
chatman commented on a change in pull request #1679: URL: https://github.com/apache/lucene-solr/pull/1679#discussion_r457248675 ## File path: solr/solrj/src/java/org/apache/solr/client/solrj/request/CollectionAdminRequest.java ## @@ -446,7 +444,6 @@ public static Modify modifyCollection(String collection, Map pro protected Boolean autoAddReplicas; protected String alias; protected String[] rule , snitch; -protected String withCollection; Review comment: Removed withCollection support. We can see if this can be implemented in an elegant way going forward. Also, with XCJF thing, this may now be irrelevant. 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] chatman commented on a change in pull request #1679: SOLR-14656: Removing autoscaling from master
chatman commented on a change in pull request #1679:
URL: https://github.com/apache/lucene-solr/pull/1679#discussion_r457247758
##
File path: solr/core/src/java/org/apache/solr/cloud/api/collections/Assign.java
##
@@ -663,17 +553,14 @@ public AssignStrategyFactory(SolrCloudManager
solrCloudManager) {
public AssignStrategy create(ClusterState clusterState, DocCollection
collection) throws IOException, InterruptedException {
@SuppressWarnings({"unchecked", "rawtypes"})
List ruleMaps = (List) collection.get("rule");
- String policyName = collection.getStr(POLICY);
@SuppressWarnings({"rawtypes"})
List snitches = (List) collection.get(SNITCH);
Strategy strategy = null;
- if ((ruleMaps == null || ruleMaps.isEmpty()) &&
!usePolicyFramework(collection, solrCloudManager)) {
+ if ((ruleMaps == null || ruleMaps.isEmpty())) {
strategy = Strategy.LEGACY;
} else if (ruleMaps != null && !ruleMaps.isEmpty()) {
Review comment:
Fixed, thanks.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[ https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161102#comment-17161102 ] Uwe Schindler commented on LUCENE-9312: --- bq. for any jar tasks Isn't the JAR task not be implemented internall by Gradle as a simple ZIP? Or do you care about the manifest? > Allow builds against arbitrary JVMs (even those unsupported by gradle) > -- > > Key: LUCENE-9312 > URL: https://issues.apache.org/jira/browse/LUCENE-9312 > Project: Lucene - Core > Issue Type: Sub-task >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Commented] (LUCENE-9312) Allow builds against arbitrary JVMs (even those unsupported by gradle)
[
https://issues.apache.org/jira/browse/LUCENE-9312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17161101#comment-17161101
]
Uwe Schindler commented on LUCENE-9312:
---
bq. warning: [options] system modules path not set in conjunction with -source
11
Javac should not pass {{-source}} and {{-target}}. To work correctly it must
pass {{--release 11}}. This is causing the issue here, because the module path
is only "correct" when release flag is used. It is not a problem to pass source
and traget (if that's automatically) but the release falg must be there.
> Allow builds against arbitrary JVMs (even those unsupported by gradle)
> --
>
> Key: LUCENE-9312
> URL: https://issues.apache.org/jira/browse/LUCENE-9312
> Project: Lucene - Core
> Issue Type: Sub-task
>Reporter: Dawid Weiss
>Assignee: Dawid Weiss
>Priority: Major
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
