[GitHub] [solr] janhoy commented on pull request #1125: Fix useGpg signing without password
janhoy commented on PR #1125: URL: https://github.com/apache/solr/pull/1125#issuecomment-1291581038 Does this remove gradle signing? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] joshgog commented on a diff in pull request #1115: Created V2 equivalent of REPLACENODE
joshgog commented on code in PR #1115:
URL: https://github.com/apache/solr/pull/1115#discussion_r1005275521
##
solr/core/src/java/org/apache/solr/handler/admin/api/ReplaceNodeAPI.java:
##
@@ -0,0 +1,119 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.handler.admin.api;
+
+import static
org.apache.solr.client.solrj.impl.BinaryResponseParser.BINARY_CONTENT_TYPE_V2;
+import static org.apache.solr.cloud.Overseer.QUEUE_OPERATION;
+import static org.apache.solr.common.params.CollectionParams.SOURCE_NODE;
+import static org.apache.solr.common.params.CollectionParams.TARGET_NODE;
+import static
org.apache.solr.handler.admin.CollectionsHandler.DEFAULT_COLLECTION_OP_TIMEOUT;
+import static
org.apache.solr.security.PermissionNameProvider.Name.COLL_EDIT_PERM;
+
+import com.fasterxml.jackson.annotation.JsonProperty;
+import io.swagger.v3.oas.annotations.Parameter;
+import io.swagger.v3.oas.annotations.media.Schema;
+import io.swagger.v3.oas.annotations.parameters.RequestBody;
+import java.util.HashMap;
+import java.util.Map;
+import javax.inject.Inject;
+import javax.ws.rs.POST;
+import javax.ws.rs.Path;
+import javax.ws.rs.PathParam;
+import javax.ws.rs.Produces;
+import org.apache.solr.client.solrj.SolrResponse;
+import org.apache.solr.common.cloud.ZkNodeProps;
+import org.apache.solr.common.params.CollectionParams;
+import org.apache.solr.common.params.CollectionParams.CollectionAction;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.handler.admin.CollectionsHandler;
+import org.apache.solr.jersey.JacksonReflectMapWriter;
+import org.apache.solr.jersey.PermissionName;
+import org.apache.solr.jersey.SolrJerseyResponse;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+
+/**
+ * V2 API for recreating replicas in one node (the source) on another node(s)
(the target).
+ *
+ * This API is analogous to the v1 /admin/collections?action=REPLACENODE
command.
+ */
+@Path("/nodes/{nodeName}/commands/replace/{targetNodeName}")
+public class ReplaceNodeAPI extends AdminAPIBase {
+
+ @Inject
+ public ReplaceNodeAPI(
+ CoreContainer coreContainer,
+ SolrQueryRequest solrQueryRequest,
+ SolrQueryResponse solrQueryResponse) {
+super(coreContainer, solrQueryRequest, solrQueryResponse);
+ }
+
+ @POST
+ @Produces({"application/json", "application/xml", BINARY_CONTENT_TYPE_V2})
+ @PermissionName(COLL_EDIT_PERM)
+ public SolrJerseyResponse replaceNode(
+ @Parameter(description = "The name of the node to be replaced.",
required = true)
+ @PathParam("nodeName")
+ String nodeName,
+ @Parameter(description = "The name of the new node.", required = true)
+ @PathParam("targetNodeName")
+ String targetNodeName,
+ @RequestBody(description = "The value of the targetNodeName", required =
true)
+ ReplaceNodeRequestBody requestBody)
+ throws Exception {
+final SolrJerseyResponse response =
instantiateJerseyResponse(SolrJerseyResponse.class);
+final CoreContainer coreContainer =
fetchAndValidateZooKeeperAwareCoreContainer();
+/** TODO Record node for log and tracing */
+final ZkNodeProps remoteMessage = createRemoteMessage(nodeName,
targetNodeName, requestBody);
+final SolrResponse remoteResponse =
+CollectionsHandler.submitCollectionApiCommand(
+coreContainer,
+coreContainer.getDistributedCollectionCommandRunner(),
+remoteMessage,
+CollectionParams.CollectionAction.REPLACENODE,
+DEFAULT_COLLECTION_OP_TIMEOUT);
+if (remoteResponse.getException() != null) {
+ throw remoteResponse.getException();
+}
+
+disableResponseCaching();
+return response;
+ }
+
+ public ZkNodeProps createRemoteMessage(
Review Comment:
> Unless you had a particular reason for excluding this from your
RequestBody POJO below and from this message-creation here, that should
probably be added?
Will add that
> Also, mostly unrelated to this PR, I notice that the [REPLACENODE
ref-guide
docs](https://solr.apache.org/guide/8_11/cluster-node-management.html#replacenode-parameters)
[GitHub] [solr] joshgog commented on a diff in pull request #1115: Created V2 equivalent of REPLACENODE
joshgog commented on code in PR #1115:
URL: https://github.com/apache/solr/pull/1115#discussion_r100520
##
solr/core/src/java/org/apache/solr/handler/admin/api/ReplaceNodeAPI.java:
##
@@ -0,0 +1,119 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.handler.admin.api;
+
+import static
org.apache.solr.client.solrj.impl.BinaryResponseParser.BINARY_CONTENT_TYPE_V2;
+import static org.apache.solr.cloud.Overseer.QUEUE_OPERATION;
+import static org.apache.solr.common.params.CollectionParams.SOURCE_NODE;
+import static org.apache.solr.common.params.CollectionParams.TARGET_NODE;
+import static
org.apache.solr.handler.admin.CollectionsHandler.DEFAULT_COLLECTION_OP_TIMEOUT;
+import static
org.apache.solr.security.PermissionNameProvider.Name.COLL_EDIT_PERM;
+
+import com.fasterxml.jackson.annotation.JsonProperty;
+import io.swagger.v3.oas.annotations.Parameter;
+import io.swagger.v3.oas.annotations.media.Schema;
+import io.swagger.v3.oas.annotations.parameters.RequestBody;
+import java.util.HashMap;
+import java.util.Map;
+import javax.inject.Inject;
+import javax.ws.rs.POST;
+import javax.ws.rs.Path;
+import javax.ws.rs.PathParam;
+import javax.ws.rs.Produces;
+import org.apache.solr.client.solrj.SolrResponse;
+import org.apache.solr.common.cloud.ZkNodeProps;
+import org.apache.solr.common.params.CollectionParams;
+import org.apache.solr.common.params.CollectionParams.CollectionAction;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.handler.admin.CollectionsHandler;
+import org.apache.solr.jersey.JacksonReflectMapWriter;
+import org.apache.solr.jersey.PermissionName;
+import org.apache.solr.jersey.SolrJerseyResponse;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+
+/**
+ * V2 API for recreating replicas in one node (the source) on another node(s)
(the target).
+ *
+ * This API is analogous to the v1 /admin/collections?action=REPLACENODE
command.
+ */
+@Path("/nodes/{nodeName}/commands/replace/{targetNodeName}")
+public class ReplaceNodeAPI extends AdminAPIBase {
+
+ @Inject
+ public ReplaceNodeAPI(
+ CoreContainer coreContainer,
+ SolrQueryRequest solrQueryRequest,
+ SolrQueryResponse solrQueryResponse) {
+super(coreContainer, solrQueryRequest, solrQueryResponse);
+ }
+
+ @POST
+ @Produces({"application/json", "application/xml", BINARY_CONTENT_TYPE_V2})
+ @PermissionName(COLL_EDIT_PERM)
+ public SolrJerseyResponse replaceNode(
+ @Parameter(description = "The name of the node to be replaced.",
required = true)
+ @PathParam("nodeName")
+ String nodeName,
+ @Parameter(description = "The name of the new node.", required = true)
+ @PathParam("targetNodeName")
+ String targetNodeName,
+ @RequestBody(description = "The value of the targetNodeName", required =
true)
Review Comment:
This is an outdated code. The current code only accepts the targetNodeName
in the request body
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] joshgog commented on a diff in pull request #1115: Created V2 equivalent of REPLACENODE
joshgog commented on code in PR #1115:
URL: https://github.com/apache/solr/pull/1115#discussion_r1005251953
##
solr/core/src/java/org/apache/solr/handler/admin/api/ReplaceNodeAPI.java:
##
@@ -0,0 +1,119 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.handler.admin.api;
+
+import static
org.apache.solr.client.solrj.impl.BinaryResponseParser.BINARY_CONTENT_TYPE_V2;
+import static org.apache.solr.cloud.Overseer.QUEUE_OPERATION;
+import static org.apache.solr.common.params.CollectionParams.SOURCE_NODE;
+import static org.apache.solr.common.params.CollectionParams.TARGET_NODE;
+import static
org.apache.solr.handler.admin.CollectionsHandler.DEFAULT_COLLECTION_OP_TIMEOUT;
+import static
org.apache.solr.security.PermissionNameProvider.Name.COLL_EDIT_PERM;
+
+import com.fasterxml.jackson.annotation.JsonProperty;
+import io.swagger.v3.oas.annotations.Parameter;
+import io.swagger.v3.oas.annotations.media.Schema;
+import io.swagger.v3.oas.annotations.parameters.RequestBody;
+import java.util.HashMap;
+import java.util.Map;
+import javax.inject.Inject;
+import javax.ws.rs.POST;
+import javax.ws.rs.Path;
+import javax.ws.rs.PathParam;
+import javax.ws.rs.Produces;
+import org.apache.solr.client.solrj.SolrResponse;
+import org.apache.solr.common.cloud.ZkNodeProps;
+import org.apache.solr.common.params.CollectionParams;
+import org.apache.solr.common.params.CollectionParams.CollectionAction;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.handler.admin.CollectionsHandler;
+import org.apache.solr.jersey.JacksonReflectMapWriter;
+import org.apache.solr.jersey.PermissionName;
+import org.apache.solr.jersey.SolrJerseyResponse;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+
+/**
+ * V2 API for recreating replicas in one node (the source) on another node(s)
(the target).
+ *
+ * This API is analogous to the v1 /admin/collections?action=REPLACENODE
command.
+ */
+@Path("/nodes/{nodeName}/commands/replace/{targetNodeName}")
+public class ReplaceNodeAPI extends AdminAPIBase {
+
+ @Inject
+ public ReplaceNodeAPI(
+ CoreContainer coreContainer,
+ SolrQueryRequest solrQueryRequest,
+ SolrQueryResponse solrQueryResponse) {
+super(coreContainer, solrQueryRequest, solrQueryResponse);
+ }
+
+ @POST
+ @Produces({"application/json", "application/xml", BINARY_CONTENT_TYPE_V2})
+ @PermissionName(COLL_EDIT_PERM)
+ public SolrJerseyResponse replaceNode(
+ @Parameter(description = "The name of the node to be replaced.",
required = true)
+ @PathParam("nodeName")
Review Comment:
Sure
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] sonatype-lift[bot] commented on a diff in pull request #1128: SOLR-16427: Evaluate and fix errorprone rules - part 4
sonatype-lift[bot] commented on code in PR #1128:
URL: https://github.com/apache/solr/pull/1128#discussion_r1005193785
##
solr/core/src/java/org/apache/solr/handler/ReplicationHandler.java:
##
@@ -1628,9 +1629,9 @@ public DirectoryFileStream(SolrParams solrParams) {
}
// Throw exception on directory traversal attempts
-protected String validateFilenameOrError(String filename) {
- if (filename != null) {
-Path filePath = Paths.get(filename);
+protected String validateFilenameOrError(String fileName) {
+ if (fileName != null) {
+Path filePath = Paths.get(fileName);
Review Comment:
*[PATH_TRAVERSAL_IN](https://find-sec-bugs.github.io/bugs.htm#PATH_TRAVERSAL_IN):*
This API
(java/nio/file/Paths.get(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path;)
reads a file whose location might be specified by user input
---
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with
***@sonatype-lift ignoreall*** to leave out all findings.
| **Command** | **Usage** |
| - | - |
| `@sonatype-lift ignore` | Leave out the above finding from this PR |
| `@sonatype-lift ignoreall` | Leave out all the existing findings from this
PR |
| `@sonatype-lift exclude ` | Exclude specified
`file\|issue\|path\|tool` from Lift findings by updating your config.toml file |
**Note:** When talking to LiftBot, you need to **refresh** the page to see
its response.
[Click here](https://github.com/apps/sonatype-lift/installations/new)
to add LiftBot to another repo.
---
Was this a good recommendation?
[ [🙁 Not
relevant](https://www.sonatype.com/lift-comment-rating?comment=348169342&lift_comment_rating=1)
] - [ [😕 Won't
fix](https://www.sonatype.com/lift-comment-rating?comment=348169342&lift_comment_rating=2)
] - [ [😑 Not critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=348169342&lift_comment_rating=3)
] - [ [🙂 Critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=348169342&lift_comment_rating=4)
] - [ [😊 Critical, fixing
now](https://www.sonatype.com/lift-comment-rating?comment=348169342&lift_comment_rating=5)
]
##
solr/core/src/java/org/apache/solr/filestore/DistribPackageStore.java:
##
@@ -72,16 +72,16 @@ public class DistribPackageStore implements PackageStore {
private final CoreContainer coreContainer;
private Map tmpFiles = new ConcurrentHashMap<>();
- private final Path solrhome;
+ private final Path solrHome;
public DistribPackageStore(CoreContainer coreContainer) {
this.coreContainer = coreContainer;
-this.solrhome = Paths.get(this.coreContainer.getSolrHome());
+this.solrHome = Paths.get(this.coreContainer.getSolrHome());
Review Comment:
*[PATH_TRAVERSAL_IN](https://find-sec-bugs.github.io/bugs.htm#PATH_TRAVERSAL_IN):*
This API
(java/nio/file/Paths.get(Ljava/lang/String;[Ljava/lang/String;)Ljava/nio/file/Path;)
reads a file whose location might be specified by user input
---
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with
***@sonatype-lift ignoreall*** to leave out all findings.
| **Command** | **Usage** |
| - | - |
| `@sonatype-lift ignore` | Leave out the above finding from this PR |
| `@sonatype-lift ignoreall` | Leave out all the existing findings from this
PR |
| `@sonatype-lift exclude ` | Exclude specified
`file\|issue\|path\|tool` from Lift findings by updating your config.toml file |
**Note:** When talking to LiftBot, you need to **refresh** the page to see
its response.
[Click here](https://github.com/apps/sonatype-lift/installations/new)
to add LiftBot to another repo.
---
Was this a good recommendation?
[ [🙁 Not
relevant](https://www.sonatype.com/lift-comment-rating?comment=348169386&lift_comment_rating=1)
] - [ [😕 Won't
fix](https://www.sonatype.com/lift-comment-rating?comment=348169386&lift_comment_rating=2)
] - [ [😑 Not critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=348169386&lift_comment_rating=3)
] - [ [🙂 Critical, will
fix](https://www.sonatype.com/lift-comment-rating?comment=348169386&lift_comment_rating=4)
] - [ [😊 Critical, fixing
now](https://www.sonatype.com/lift-comment-rating?comment=348169386&lift_comment_rating=5)
]
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail:
[jira] [Resolved] (SOLR-16416) Fix silently failing Overseer Election joinAtHead during testDesignatedOverseerRestarts
[ https://issues.apache.org/jira/browse/SOLR-16416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Houston Putman resolved SOLR-16416. --- Fix Version/s: 9.1 main (10.0) Assignee: Houston Putman Resolution: Fixed > Fix silently failing Overseer Election joinAtHead during > testDesignatedOverseerRestarts > --- > > Key: SOLR-16416 > URL: https://issues.apache.org/jira/browse/SOLR-16416 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Houston Putman >Assignee: Houston Putman >Priority: Major > Fix For: 9.1, main (10.0) > > Time Spent: 1h > Remaining Estimate: 0h > > OverseerRolesTest.testDesignatedOverseerRestarts has been failing > consistently (around 2.5% of the time). I think this is because > LeaderElection.joinElection does not respect the joinAtHead flag, if > connectionIssues happen while setting the leader election nodes. > LeaderElection does not use the automatic retryOnConnLoss flags when doing zk > operations. Instead, it waits for an error to come back, and it handles the > retry itself. This is fine for the normal case, because it checks if node is > represented in the leaderElection child nodes, and if so it ignores the > connection loss. However when doing joinAtHead, if the childNode exists, but > isn't at the place it should be, then the manual retry should be exercised. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16416) Fix silently failing Overseer Election joinAtHead during testDesignatedOverseerRestarts
[ https://issues.apache.org/jira/browse/SOLR-16416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624156#comment-17624156 ] ASF subversion and git services commented on SOLR-16416: Commit e636590600206c8cae9f88fabab5f962fe984937 in solr's branch refs/heads/branch_9_1 from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=e6365906002 ] SOLR-16416: retry overseerPrioritizer ops on failure. (#1129) (cherry picked from commit 1738098b348a27b3dd5c4f64e12115de20b74b17) > Fix silently failing Overseer Election joinAtHead during > testDesignatedOverseerRestarts > --- > > Key: SOLR-16416 > URL: https://issues.apache.org/jira/browse/SOLR-16416 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Houston Putman >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > OverseerRolesTest.testDesignatedOverseerRestarts has been failing > consistently (around 2.5% of the time). I think this is because > LeaderElection.joinElection does not respect the joinAtHead flag, if > connectionIssues happen while setting the leader election nodes. > LeaderElection does not use the automatic retryOnConnLoss flags when doing zk > operations. Instead, it waits for an error to come back, and it handles the > retry itself. This is fine for the normal case, because it checks if node is > represented in the leaderElection child nodes, and if so it ignores the > connection loss. However when doing joinAtHead, if the childNode exists, but > isn't at the place it should be, then the manual retry should be exercised. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16363) DirectUpdateHandler2 should not throw UnknownFormatConversionException
[
https://issues.apache.org/jira/browse/SOLR-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624147#comment-17624147
]
ASF subversion and git services commented on SOLR-16363:
Commit b4afb37e1abcb24a2910f41e55fddcf6d5459586 in solr's branch
refs/heads/branch_9x from Kevin Risden
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=b4afb37e1ab ]
SOLR-16363: DirectUpdateHandler2 should not throw
UnknownFormatConversionException (#1121)
> DirectUpdateHandler2 should not throw UnknownFormatConversionException
> --
>
> Key: SOLR-16363
> URL: https://issues.apache.org/jira/browse/SOLR-16363
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 9.0, 8.11.2, 9.1
>Reporter: Aman Verma
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: main (10.0), 9.2
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In certain situation, to handle IllegalArgumentException while adding doc to
> solr is linked below
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L249|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L250]
> EDIT: Adding Code piece for current main branch:
> [https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L314]
>
> This can be problematic if IllegalArgumentException (of the following format)
> is thrown during processing of docs (in my case it was via Filters to
> URL-Decode a string)
>
> {code:java}
> java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in
> escape (%) pattern - Error at index 0 in: "sy"{code}
> The _iae.getMessage()_ in this case contains "{*}%){*}" which conflicts with
> String.format which would further throw
> {code:java}
> java.util.UnknownFormatConversionException: Conversion = ')'
> at java.util.Formatter.checkText(Unknown Source) ~[?:?]
> at java.util.Formatter.parse(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.lang.String.format(Unknown Source) ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:249){code}
> This particular exception is not caught and as a result the BAD_REQUEST was
> never returned to the client along with failure point in the chain.
> The ticket is a proposal to make this more robust i.e., in this particular
> situation either getMessage() could replaceAll "%" or perhaps another try?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16363) DirectUpdateHandler2 should not throw UnknownFormatConversionException
[
https://issues.apache.org/jira/browse/SOLR-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624148#comment-17624148
]
ASF subversion and git services commented on SOLR-16363:
Commit fd55c602a85ba259e58b25a3068e41ce40b9a79e in solr's branch
refs/heads/branch_9x from Kevin Risden
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=fd55c602a85 ]
SOLR-16363: DirectUpdateHandler2 remove String.format from error logging (#1124)
> DirectUpdateHandler2 should not throw UnknownFormatConversionException
> --
>
> Key: SOLR-16363
> URL: https://issues.apache.org/jira/browse/SOLR-16363
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 9.0, 8.11.2, 9.1
>Reporter: Aman Verma
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: main (10.0), 9.2
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In certain situation, to handle IllegalArgumentException while adding doc to
> solr is linked below
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L249|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L250]
> EDIT: Adding Code piece for current main branch:
> [https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L314]
>
> This can be problematic if IllegalArgumentException (of the following format)
> is thrown during processing of docs (in my case it was via Filters to
> URL-Decode a string)
>
> {code:java}
> java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in
> escape (%) pattern - Error at index 0 in: "sy"{code}
> The _iae.getMessage()_ in this case contains "{*}%){*}" which conflicts with
> String.format which would further throw
> {code:java}
> java.util.UnknownFormatConversionException: Conversion = ')'
> at java.util.Formatter.checkText(Unknown Source) ~[?:?]
> at java.util.Formatter.parse(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.lang.String.format(Unknown Source) ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:249){code}
> This particular exception is not caught and as a result the BAD_REQUEST was
> never returned to the client along with failure point in the chain.
> The ticket is a proposal to make this more robust i.e., in this particular
> situation either getMessage() could replaceAll "%" or perhaps another try?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16363) DirectUpdateHandler2 should not throw UnknownFormatConversionException
[
https://issues.apache.org/jira/browse/SOLR-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16363:
Fix Version/s: 9.2
> DirectUpdateHandler2 should not throw UnknownFormatConversionException
> --
>
> Key: SOLR-16363
> URL: https://issues.apache.org/jira/browse/SOLR-16363
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 9.0, 8.11.2, 9.1
>Reporter: Aman Verma
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: main (10.0), 9.2
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In certain situation, to handle IllegalArgumentException while adding doc to
> solr is linked below
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L249|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L250]
> EDIT: Adding Code piece for current main branch:
> [https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L314]
>
> This can be problematic if IllegalArgumentException (of the following format)
> is thrown during processing of docs (in my case it was via Filters to
> URL-Decode a string)
>
> {code:java}
> java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in
> escape (%) pattern - Error at index 0 in: "sy"{code}
> The _iae.getMessage()_ in this case contains "{*}%){*}" which conflicts with
> String.format which would further throw
> {code:java}
> java.util.UnknownFormatConversionException: Conversion = ')'
> at java.util.Formatter.checkText(Unknown Source) ~[?:?]
> at java.util.Formatter.parse(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.lang.String.format(Unknown Source) ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:249){code}
> This particular exception is not caught and as a result the BAD_REQUEST was
> never returned to the client along with failure point in the chain.
> The ticket is a proposal to make this more robust i.e., in this particular
> situation either getMessage() could replaceAll "%" or perhaps another try?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16363) DirectUpdateHandler2 should not throw UnknownFormatConversionException
[
https://issues.apache.org/jira/browse/SOLR-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16363:
Resolution: Fixed
Status: Resolved (was: Patch Available)
Thanks for the nice error report [~averma]
> DirectUpdateHandler2 should not throw UnknownFormatConversionException
> --
>
> Key: SOLR-16363
> URL: https://issues.apache.org/jira/browse/SOLR-16363
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 9.0, 8.11.2, 9.1
>Reporter: Aman Verma
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: main (10.0), 9.2
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In certain situation, to handle IllegalArgumentException while adding doc to
> solr is linked below
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L249|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L250]
> EDIT: Adding Code piece for current main branch:
> [https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L314]
>
> This can be problematic if IllegalArgumentException (of the following format)
> is thrown during processing of docs (in my case it was via Filters to
> URL-Decode a string)
>
> {code:java}
> java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in
> escape (%) pattern - Error at index 0 in: "sy"{code}
> The _iae.getMessage()_ in this case contains "{*}%){*}" which conflicts with
> String.format which would further throw
> {code:java}
> java.util.UnknownFormatConversionException: Conversion = ')'
> at java.util.Formatter.checkText(Unknown Source) ~[?:?]
> at java.util.Formatter.parse(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.lang.String.format(Unknown Source) ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:249){code}
> This particular exception is not caught and as a result the BAD_REQUEST was
> never returned to the client along with failure point in the chain.
> The ticket is a proposal to make this more robust i.e., in this particular
> situation either getMessage() could replaceAll "%" or perhaps another try?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16416) Fix silently failing Overseer Election joinAtHead during testDesignatedOverseerRestarts
[ https://issues.apache.org/jira/browse/SOLR-16416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624145#comment-17624145 ] ASF subversion and git services commented on SOLR-16416: Commit 5656eb4c5a3513d7e14ea5ea3b35f1389d1aa037 in solr's branch refs/heads/branch_9x from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=5656eb4c5a3 ] SOLR-16416: Register all handlers before doing overseer operations (#1129) Also retry overseerPrioritizer ops on failure. (cherry picked from commit 1738098b348a27b3dd5c4f64e12115de20b74b17) > Fix silently failing Overseer Election joinAtHead during > testDesignatedOverseerRestarts > --- > > Key: SOLR-16416 > URL: https://issues.apache.org/jira/browse/SOLR-16416 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Houston Putman >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > OverseerRolesTest.testDesignatedOverseerRestarts has been failing > consistently (around 2.5% of the time). I think this is because > LeaderElection.joinElection does not respect the joinAtHead flag, if > connectionIssues happen while setting the leader election nodes. > LeaderElection does not use the automatic retryOnConnLoss flags when doing zk > operations. Instead, it waits for an error to come back, and it handles the > retry itself. This is fine for the normal case, because it checks if node is > represented in the leaderElection child nodes, and if so it ignores the > connection loss. However when doing joinAtHead, if the childNode exists, but > isn't at the place it should be, then the manual retry should be exercised. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16363) DirectUpdateHandler2 should not throw UnknownFormatConversionException
[
https://issues.apache.org/jira/browse/SOLR-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16363:
Fix Version/s: main (10.0)
(was: 9.2)
> DirectUpdateHandler2 should not throw UnknownFormatConversionException
> --
>
> Key: SOLR-16363
> URL: https://issues.apache.org/jira/browse/SOLR-16363
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 9.0, 8.11.2, 9.1
>Reporter: Aman Verma
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: main (10.0)
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In certain situation, to handle IllegalArgumentException while adding doc to
> solr is linked below
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L249|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L250]
> EDIT: Adding Code piece for current main branch:
> [https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L314]
>
> This can be problematic if IllegalArgumentException (of the following format)
> is thrown during processing of docs (in my case it was via Filters to
> URL-Decode a string)
>
> {code:java}
> java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in
> escape (%) pattern - Error at index 0 in: "sy"{code}
> The _iae.getMessage()_ in this case contains "{*}%){*}" which conflicts with
> String.format which would further throw
> {code:java}
> java.util.UnknownFormatConversionException: Conversion = ')'
> at java.util.Formatter.checkText(Unknown Source) ~[?:?]
> at java.util.Formatter.parse(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.lang.String.format(Unknown Source) ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:249){code}
> This particular exception is not caught and as a result the BAD_REQUEST was
> never returned to the client along with failure point in the chain.
> The ticket is a proposal to make this more robust i.e., in this particular
> situation either getMessage() could replaceAll "%" or perhaps another try?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16416) Fix silently failing Overseer Election joinAtHead during testDesignatedOverseerRestarts
[ https://issues.apache.org/jira/browse/SOLR-16416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624143#comment-17624143 ] ASF subversion and git services commented on SOLR-16416: Commit 1738098b348a27b3dd5c4f64e12115de20b74b17 in solr's branch refs/heads/main from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=1738098b348 ] SOLR-16416: Register all handlers before doing overseer operations (#1129) Also retry overseerPrioritizer ops on failure. > Fix silently failing Overseer Election joinAtHead during > testDesignatedOverseerRestarts > --- > > Key: SOLR-16416 > URL: https://issues.apache.org/jira/browse/SOLR-16416 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Houston Putman >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > OverseerRolesTest.testDesignatedOverseerRestarts has been failing > consistently (around 2.5% of the time). I think this is because > LeaderElection.joinElection does not respect the joinAtHead flag, if > connectionIssues happen while setting the leader election nodes. > LeaderElection does not use the automatic retryOnConnLoss flags when doing zk > operations. Instead, it waits for an error to come back, and it handles the > retry itself. This is fine for the normal case, because it checks if node is > represented in the leaderElection child nodes, and if so it ignores the > connection loss. However when doing joinAtHead, if the childNode exists, but > isn't at the place it should be, then the manual retry should be exercised. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] HoustonPutman merged pull request #1129: SOLR-16416: Retry overseerPrioritizer ops on failure
HoustonPutman merged PR #1129: URL: https://github.com/apache/solr/pull/1129 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16363) DirectUpdateHandler2 should not throw UnknownFormatConversionException
[
https://issues.apache.org/jira/browse/SOLR-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624142#comment-17624142
]
ASF subversion and git services commented on SOLR-16363:
Commit 57719fedef7148c311b07c8ac246e98268ab9707 in solr's branch
refs/heads/main from Kevin Risden
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=57719fedef7 ]
SOLR-16363: DirectUpdateHandler2 remove String.format from error logging (#1124)
> DirectUpdateHandler2 should not throw UnknownFormatConversionException
> --
>
> Key: SOLR-16363
> URL: https://issues.apache.org/jira/browse/SOLR-16363
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 9.0, 8.11.2, 9.1
>Reporter: Aman Verma
>Assignee: Kevin Risden
>Priority: Minor
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In certain situation, to handle IllegalArgumentException while adding doc to
> solr is linked below
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L249|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L250]
> EDIT: Adding Code piece for current main branch:
> [https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L314]
>
> This can be problematic if IllegalArgumentException (of the following format)
> is thrown during processing of docs (in my case it was via Filters to
> URL-Decode a string)
>
> {code:java}
> java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in
> escape (%) pattern - Error at index 0 in: "sy"{code}
> The _iae.getMessage()_ in this case contains "{*}%){*}" which conflicts with
> String.format which would further throw
> {code:java}
> java.util.UnknownFormatConversionException: Conversion = ')'
> at java.util.Formatter.checkText(Unknown Source) ~[?:?]
> at java.util.Formatter.parse(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.lang.String.format(Unknown Source) ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:249){code}
> This particular exception is not caught and as a result the BAD_REQUEST was
> never returned to the client along with failure point in the chain.
> The ticket is a proposal to make this more robust i.e., in this particular
> situation either getMessage() could replaceAll "%" or perhaps another try?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16363) DirectUpdateHandler2 should not throw UnknownFormatConversionException
[
https://issues.apache.org/jira/browse/SOLR-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16363:
Fix Version/s: 9.2
> DirectUpdateHandler2 should not throw UnknownFormatConversionException
> --
>
> Key: SOLR-16363
> URL: https://issues.apache.org/jira/browse/SOLR-16363
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 9.0, 8.11.2, 9.1
>Reporter: Aman Verma
>Assignee: Kevin Risden
>Priority: Minor
> Fix For: 9.2
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In certain situation, to handle IllegalArgumentException while adding doc to
> solr is linked below
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L249|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L250]
> EDIT: Adding Code piece for current main branch:
> [https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L314]
>
> This can be problematic if IllegalArgumentException (of the following format)
> is thrown during processing of docs (in my case it was via Filters to
> URL-Decode a string)
>
> {code:java}
> java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in
> escape (%) pattern - Error at index 0 in: "sy"{code}
> The _iae.getMessage()_ in this case contains "{*}%){*}" which conflicts with
> String.format which would further throw
> {code:java}
> java.util.UnknownFormatConversionException: Conversion = ')'
> at java.util.Formatter.checkText(Unknown Source) ~[?:?]
> at java.util.Formatter.parse(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.lang.String.format(Unknown Source) ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:249){code}
> This particular exception is not caught and as a result the BAD_REQUEST was
> never returned to the client along with failure point in the chain.
> The ticket is a proposal to make this more robust i.e., in this particular
> situation either getMessage() could replaceAll "%" or perhaps another try?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk merged pull request #1124: SOLR-16363: DirectUpdateHandler2 remove String.format from error logging
risdenk merged PR #1124: URL: https://github.com/apache/solr/pull/1124 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #1116: SOLR-16427: Evaluate and fix errorprone rules - part 3
risdenk commented on code in PR #1116:
URL: https://github.com/apache/solr/pull/1116#discussion_r1005148149
##
solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsUpdateLog.java:
##
@@ -131,24 +131,24 @@ public void init(UpdateHandler uhandler, SolrCore core) {
if (debug) {
log.debug(
"UpdateHandler init: tlogDir={}, next id={} this is a reopen or
double init ... nothing else to do.",
- tlogDir,
+ hdfsTlogDir,
id);
}
versionInfo.reload();
return;
}
}
-tlogDir = new Path(dataDir, TLOG_NAME);
+hdfsTlogDir = new Path(dataDir, TLOG_NAME);
Review Comment:
@sonatype-lift ignore
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] sonatype-lift[bot] commented on a diff in pull request #1116: SOLR-16427: Evaluate and fix errorprone rules - part 3
sonatype-lift[bot] commented on code in PR #1116:
URL: https://github.com/apache/solr/pull/1116#discussion_r1005148184
##
solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsUpdateLog.java:
##
@@ -131,24 +131,24 @@ public void init(UpdateHandler uhandler, SolrCore core) {
if (debug) {
log.debug(
"UpdateHandler init: tlogDir={}, next id={} this is a reopen or
double init ... nothing else to do.",
- tlogDir,
+ hdfsTlogDir,
id);
}
versionInfo.reload();
return;
}
}
-tlogDir = new Path(dataDir, TLOG_NAME);
+hdfsTlogDir = new Path(dataDir, TLOG_NAME);
Review Comment:
I've recorded this as ignored for this pull request.
If you change your mind, just comment `@sonatype-lift unignore`.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #1116: SOLR-16427: Evaluate and fix errorprone rules - part 3
risdenk commented on code in PR #1116:
URL: https://github.com/apache/solr/pull/1116#discussion_r1005147235
##
solr/core/src/java/org/apache/solr/util/hll/SerializationUtil.java:
##
@@ -137,8 +137,8 @@ public static byte packVersionByte(final int schemaVersion,
final int typeOrdina
*
* If 'explicit-disabled' is chosen, this value should be
0.
* If 'auto' is chosen, this value should be 63.
- * If a cutoff of 2n is desired, for 0 <= n <
31, this value
- * should be n + 1.
+ * If a cutoff of 2n is desired, for {@code 0 <=
n < 31}, this
+ * value should be {@code n + 1}.
Review Comment:
fixed in 74ffc2219930d742f38dacee4091d7624c0ddcaf
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] HoustonPutman commented on a diff in pull request #1129: SOLR-16416: Retry overseerPrioritizer ops on failure
HoustonPutman commented on code in PR #1129:
URL: https://github.com/apache/solr/pull/1129#discussion_r1005143310
##
solr/core/src/java/org/apache/solr/cloud/OverseerNodePrioritizer.java:
##
@@ -133,6 +135,23 @@ public synchronized void prioritizeOverseerNodes(String
overseerId) throws Excep
overseer.sendQuitToOverseer(OverseerTaskProcessor.getLeaderId(zkStateReader.getZkClient()));
}
+ private void invokeOverseerOpWithRetries(String electionNode, String op, int
retryCount) {
+boolean successful = false;
+for (int i = 0; i < retryCount && !successful; i++) {
+ try {
+invokeOverseerOp(electionNode, op);
+successful = true;
+ } catch (SolrException e) {
+if (i < retryCount - 1) {
Review Comment:
thanks for catching 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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624132#comment-17624132
]
ASF subversion and git services commented on SOLR-16412:
Commit 6340a4abba37d535831b74703a7ca390eff167b7 in solr's branch
refs/heads/branch_9_1 from Kevin Risden
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=6340a4abba3 ]
SOLR-16412: Fix TestSizeLimitedDistributedMap LinkedList compilation error
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, 9.1, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 9.1, main (10.0)
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16412:
Fix Version/s: 9.1
main (10.0)
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, 9.1, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Fix For: 9.1, main (10.0)
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16412:
Priority: Major (was: Blocker)
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, 9.1, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Major
> Fix For: 9.1, main (10.0)
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624128#comment-17624128
]
ASF subversion and git services commented on SOLR-16412:
Commit 85772c206f75ea44e267b7679b724f4f65ab40be in solr's branch
refs/heads/branch_9x from Kevin Risden
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=85772c206f7 ]
SOLR-16412: Fix TestSizeLimitedDistributedMap LinkedList compilation error
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, 9.1, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624124#comment-17624124
]
ASF subversion and git services commented on SOLR-16412:
Commit 2f6818886e90f8edebf3b71e0a96ccc0c9b6947e in solr's branch
refs/heads/main from Kevin Risden
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=2f6818886e9 ]
SOLR-16412: Fix TestSizeLimitedDistributedMap LinkedList compilation error
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, 9.1, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #1129: SOLR-16416: Retry overseerPrioritizer ops on failure
risdenk commented on code in PR #1129:
URL: https://github.com/apache/solr/pull/1129#discussion_r1005095748
##
solr/core/src/java/org/apache/solr/cloud/OverseerNodePrioritizer.java:
##
@@ -133,6 +135,23 @@ public synchronized void prioritizeOverseerNodes(String
overseerId) throws Excep
overseer.sendQuitToOverseer(OverseerTaskProcessor.getLeaderId(zkStateReader.getZkClient()));
}
+ private void invokeOverseerOpWithRetries(String electionNode, String op, int
retryCount) {
+boolean successful = false;
+for (int i = 0; i < retryCount && !successful; i++) {
+ try {
+invokeOverseerOp(electionNode, op);
+successful = true;
+ } catch (SolrException e) {
+if (i < retryCount - 1) {
Review Comment:
it looks like maybe a sleep was added then removed? not sure at least now
there is no sleep?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624085#comment-17624085
]
ASF subversion and git services commented on SOLR-16412:
Commit 5294c82c3cd535604be5fce48f86f6ecedc187bc in solr's branch
refs/heads/branch_9_1 from patsonluk
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=5294c82c3cd ]
SOLR-16412 : Race condition in SizeLimitedDistributedMap for cleanup (#1032)
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, 9.1, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624084#comment-17624084
]
ASF subversion and git services commented on SOLR-16412:
Commit a98faa932b92a07f71a7331dabca7ac24fc0808d in solr's branch
refs/heads/branch_9x from patsonluk
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=a98faa932b9 ]
SOLR-16412 : Race condition in SizeLimitedDistributedMap for cleanup (#1032)
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, 9.1, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624083#comment-17624083
]
ASF subversion and git services commented on SOLR-16412:
Commit babcb9e633d1e36e0c866fef27d5a97bc10cea91 in solr's branch
refs/heads/main from patsonluk
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=babcb9e633d ]
SOLR-16412 : Race condition in SizeLimitedDistributedMap for cleanup (#1032)
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, 9.1, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] noblepaul commented on pull request #1032: SOLR-16412 : Race condition in SizeLimitedDistributedMap for cleanup
noblepaul commented on PR #1032: URL: https://github.com/apache/solr/pull/1032#issuecomment-1291267801 thanks @patsonluk -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] noblepaul merged pull request #1032: SOLR-16412 : Race condition in SizeLimitedDistributedMap for cleanup
noblepaul merged PR #1032: URL: https://github.com/apache/solr/pull/1032 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624074#comment-17624074
]
Patson Luk commented on SOLR-16412:
---
[~noblepaul][~ichattopadhyaya] It's probably a good idea to push this to 9_x
and 9_1 too?
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, 9.1, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patson Luk updated SOLR-16412:
--
Affects Version/s: 9.1
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, 9.1, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16412) Race condition could trigger error on concurrent SizeLimitedDistributedMap cleanup
[
https://issues.apache.org/jira/browse/SOLR-16412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patson Luk updated SOLR-16412:
--
Priority: Blocker (was: Major)
> Race condition could trigger error on concurrent SizeLimitedDistributedMap
> cleanup
> --
>
> Key: SOLR-16412
> URL: https://issues.apache.org/jira/browse/SOLR-16412
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
>Affects Versions: 8.8, main (10.0)
>Reporter: Patson Luk
>Assignee: Ishan Chattopadhyaya
>Priority: Blocker
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> h2. Description
> Exception below is observed while updating the `completedMap` field in
> `OverseerTaskProcessor` :
> {{o.a.s.c.OverseerTaskProcessor
> :org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode =
> NoNode for
> /overseer/collection-map-completed/mn-736f6c726d616e2d312d3138393038373039383731303932353331}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:118)}}
> {{at org.apache.zookeeper.KeeperException.create(KeeperException.java:54)}}
> {{at org.apache.zookeeper.ZooKeeper.delete(ZooKeeper.java:2001)}}
> {{at
> org.apache.solr.common.cloud.SolrZkClient.lambda$delete$1(SolrZkClient.java:264)}}
> {{at
> org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:71)}}
> {{at org.apache.solr.common.cloud.SolrZkClient.delete(SolrZkClient.java:263)}}
> {{at
> org.apache.solr.cloud.SizeLimitedDistributedMap.put(SizeLimitedDistributedMap.java:76)}}
> {{at
> org.apache.solr.cloud.OverseerTaskProcessor$Runner.run(OverseerTaskProcessor.java:538)}}
> {{at
> org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:218)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)}}
> {{at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)}}
> h2. Cause
> Based on the stack trace, `SizeLimitedDistributedMap` had reached the limit
> and attempted to cleanup entries:
> [https://github.com/fullstorydev/lucene-solr/blob/75e89929eb360b513ee864aeb23a80c049747246/solr/core/src/java/org/apache/solr/cloud/SizeLimitedDistributedMap.java#L73-L80]
> However, when it performs the actual deletion, it failed with
> `NoNodeException`
> This is likely caused by race condition as multiple threads can enter the
> same code block and try to delete same list of children which the slower
> threads can delete on child node that no longer exists.
>
> Such condition can be reproduced by unit test case, which will be included in
> the PR
> h2. Solution
> Although we could enforce synchronization to prevent threads from purging the
> same set of child nodes, it might not be desirable to add extra blocking.
> Instead, it's probably safe to ignore the `KeeperException.NoNodeException`
> if such node is no longer there for the purge operation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16495) Update first page of ref guide ("Introduction to Solr")
[
https://issues.apache.org/jira/browse/SOLR-16495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624072#comment-17624072
]
Gus Heck commented on SOLR-16495:
-
Since this is just ref guide and hopefully not controversial I'll try to push
this to main and 9x tomorrow if there are no suggestions/edits. It could go to
9.1 if folks like it and that won't derail the release.
> Update first page of ref guide ("Introduction to Solr")
> ---
>
> Key: SOLR-16495
> URL: https://issues.apache.org/jira/browse/SOLR-16495
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 9.0, main (10.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I happened to read this page in the ref guide the other day, and found it to
> be inconsistently voiced, and simultaneously under and over selling Solr. I
> intend to submit a PR with a suggested update with the goal of a more
> consistent flow, more links and a more carefully worded 10,000ft view of
> Solr.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16303) Upgrade to Lucene 9.3
[ https://issues.apache.org/jira/browse/SOLR-16303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-16303: Fix Version/s: 9.1 (was: main (10.0)) > Upgrade to Lucene 9.3 > - > > Key: SOLR-16303 > URL: https://issues.apache.org/jira/browse/SOLR-16303 > Project: Solr > Issue Type: Task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Critical > Fix For: 9.1 > > Time Spent: 20m > Remaining Estimate: 0h > > Lucene 9.3 is coming soon, we should try to stay current and at least get on > 9.2 if we can. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] HoustonPutman commented on pull request #1129: SOLR-16416: Retry overseerPrioritizer ops on failure
HoustonPutman commented on PR #1129: URL: https://github.com/apache/solr/pull/1129#issuecomment-1291200682 @gerlowskija I have actually fixed the underlying issue. We were running overseer ops before actually registering all of the Solr handlers. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gus-asf opened a new pull request, #1130: SOLR-16495 - new text for introduction to solr page.
gus-asf opened a new pull request, #1130: URL: https://github.com/apache/solr/pull/1130 https://issues.apache.org/jira/browse/SOLR-16495 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-14278) data loss during live shard split if leader dies
[ https://issues.apache.org/jira/browse/SOLR-14278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated SOLR-14278: Attachment: SOLR-14278.patch Status: Open (was: Open) Attached is an updated patch that applies to main.It's internally failing before it gets to the end... connection refused errors. I didn't look closely -- I just tried it and hoped for luck but got none. Anyone who wants to look further should start a fresh PR from the new Git solr repo, not the old lucene-solr joint repo. > data loss during live shard split if leader dies > > > Key: SOLR-14278 > URL: https://issues.apache.org/jira/browse/SOLR-14278 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley >Priority: Major > Attachments: SOLR-14278.patch > > Time Spent: 10m > Remaining Estimate: 0h > > While trying to develop better tests for shared storage (SOLR-13101), I ran > across another failure for normal replica types as well (one of the first > things I do when a test fails for shared storage is to try and validate that > normal NRT replicas succeed.) The PR I'll open has a test adapted from the > one in SOLR-13813 for master. > Scenario: > - indexing is happening during shard split > - leader is killed shortly after (before the split has finished) and never > brought back up > - there are often some missing documents at the end > While it's possible that the simulated killing of the node in the unit test > is imperfect, I haven't reproduced a failure if I comment out the split > command and just kill the leader. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] dsmiley commented on pull request #1088: SOLR-16473: Fix race condition in shard split when a sub-shard is put in recovery state.
dsmiley commented on PR #1088: URL: https://github.com/apache/solr/pull/1088#issuecomment-1291167131 The bug was found/fixed locally in May of 2020. I see that Yonik's SOLR-14278 is a test for shard split errors (not committed; seems rather WIP/DRAFT). I took the old patch and updated it to apply, and the test seems to fail for inexplicable reasons about not being able to connect; it didn't get to the point where it makes a final assertion. So I don't know; maybe this bug fix helps. I don't think we need a test to reproduce a race condition to gate committing improvements. It'd be nice but we don't have one. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #1129: SOLR-16416: Retry overseerPrioritizer ops on failure
risdenk commented on code in PR #1129:
URL: https://github.com/apache/solr/pull/1129#discussion_r1004960908
##
solr/core/src/java/org/apache/solr/cloud/OverseerNodePrioritizer.java:
##
@@ -133,6 +135,23 @@ public synchronized void prioritizeOverseerNodes(String
overseerId) throws Excep
overseer.sendQuitToOverseer(OverseerTaskProcessor.getLeaderId(zkStateReader.getZkClient()));
}
+ private void invokeOverseerOpWithRetries(String electionNode, String op, int
retryCount) {
+boolean successful = false;
+for (int i = 0; i < retryCount && !successful; i++) {
+ try {
+invokeOverseerOp(electionNode, op);
+successful = true;
+ } catch (SolrException e) {
+if (i < retryCount - 1) {
Review Comment:
do we want some sort of sleep/wait here?
##
solr/core/src/java/org/apache/solr/cloud/OverseerNodePrioritizer.java:
##
@@ -20,7 +20,9 @@
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
+
Review Comment:
`./gradlew tidy` most likely needed?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] HoustonPutman opened a new pull request, #1129: SOLR-16416: Retry overseerPrioritizer ops on failure
HoustonPutman opened a new pull request, #1129: URL: https://github.com/apache/solr/pull/1129 https://issues.apache.org/jira/browse/SOLR-16416 This should fix the failing test. No idea why the endpoints noted in the JIRA were unavailable when restarting the test nodes, but anyways it is good to retry this logic. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] sonatype-lift[bot] commented on a diff in pull request #1128: SOLR-16427: Evaluate and fix errorprone rules - part 4
sonatype-lift[bot] commented on code in PR #1128:
URL: https://github.com/apache/solr/pull/1128#discussion_r1004945806
##
solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsUpdateLog.java:
##
@@ -131,24 +131,24 @@ public void init(UpdateHandler uhandler, SolrCore core) {
if (debug) {
log.debug(
"UpdateHandler init: tlogDir={}, next id={} this is a reopen or
double init ... nothing else to do.",
- tlogDir,
+ hdfsTlogDir,
id);
}
versionInfo.reload();
return;
}
}
-tlogDir = new Path(dataDir, TLOG_NAME);
+hdfsTlogDir = new Path(dataDir, TLOG_NAME);
Review Comment:
💬 11 similar findings have been found in this PR
---
*THREAD_SAFETY_VIOLATION:* Read/Write race. Non-private method
`HdfsUpdateLog.init(...)` reads without synchronization from `this.dataDir`.
Potentially races with write in method `HdfsUpdateLog.init(...)`.
Reporting because this access may occur on a background thread.
---
🔎 Expand here to view all instances of this
finding
| **File Path** | **Line Number** |
| - | - |
| solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsUpdateLog.java
|
[331](https://github.com/risdenk/solr/blob/a4d6ee160c165fd90cdf50d4acf1746338b6fc2d/solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsUpdateLog.java#L331)|
|
solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java
|
[414](https://github.com/risdenk/solr/blob/a4d6ee160c165fd90cdf50d4acf1746338b6fc2d/solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java#L414)|
|
solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java
|
[483](https://github.com/risdenk/solr/blob/a4d6ee160c165fd90cdf50d4acf1746338b6fc2d/solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java#L483)|
|
solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java
|
[436](https://github.com/risdenk/solr/blob/a4d6ee160c165fd90cdf50d4acf1746338b6fc2d/solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java#L436)|
| solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsUpdateLog.java
|
[145](https://github.com/risdenk/solr/blob/a4d6ee160c165fd90cdf50d4acf1746338b6fc2d/solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsUpdateLog.java#L145)|
|
solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java
|
[441](https://github.com/risdenk/solr/blob/a4d6ee160c165fd90cdf50d4acf1746338b6fc2d/solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java#L441)|
| solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsUpdateLog.java
|
[175](https://github.com/risdenk/solr/blob/a4d6ee160c165fd90cdf50d4acf1746338b6fc2d/solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsUpdateLog.java#L175)|
|
solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java
|
[460](https://github.com/risdenk/solr/blob/a4d6ee160c165fd90cdf50d4acf1746338b6fc2d/solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java#L460)|
|
solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java
|
[474](https://github.com/risdenk/solr/blob/a4d6ee160c165fd90cdf50d4acf1746338b6fc2d/solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java#L474)|
|
solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java
|
[448](https://github.com/risdenk/solr/blob/a4d6ee160c165fd90cdf50d4acf1746338b6fc2d/solr/modules/hdfs/src/java/org/apache/solr/hdfs/update/HdfsTransactionLog.java#L448)|
Showing 10 of 11 findings. https://lift.sonatype.com/results/github.com/apache/solr/01GG8BG6SH6MMAAE4J6BRRY82V?t=Infer|THREAD_SAFETY_VIOLATION"
target="_blank">Visit the Lift Web Console to see all.
---
ℹ️ Learn about @sonatype-lift commands
You can reply with the following commands. For example, reply with
***@sonatype-lift ignoreall*** to leave out all findings.
| **Command** | **Usage** |
| - | - |
| `@sonatype-lift ignore` | Leave out the above finding from this PR |
| `@sonatype-lift ignoreall` | Leave out all the existing findings from this
PR |
| `@sonatype-lift exclude ` | Exclude specified
`file\|issue\|path\|tool` from Lift findings by updating your config.toml file |
**Note:** When talking to LiftBot, you need to **refresh** the page to see
its response.
[Click here](https://github.com/apps/sonatype-lift/installations/new)
to add LiftBot to another repo.
---
Was this a good recommendation?
[ [🙁 Not
relevant](https://www.sonatype.com/lift-comment-rating?comment=348112235&lift_comment_rating=1)
] - [ [😕 Won't
fix](https://www.sonatype.com/lift-comment-rating?comment=34811
[GitHub] [solr] risdenk commented on a diff in pull request #1116: SOLR-16427: Evaluate and fix errorprone rules - part 3
risdenk commented on code in PR #1116:
URL: https://github.com/apache/solr/pull/1116#discussion_r1004945487
##
solr/core/src/java/org/apache/solr/util/hll/SerializationUtil.java:
##
@@ -137,8 +137,8 @@ public static byte packVersionByte(final int schemaVersion,
final int typeOrdina
*
* If 'explicit-disabled' is chosen, this value should be
0.
* If 'auto' is chosen, this value should be 63.
- * If a cutoff of 2n is desired, for 0 <= n <
31, this value
- * should be n + 1.
+ * If a cutoff of 2n is desired, for {@code 0 <=
n < 31}, this
+ * value should be {@code n + 1}.
Review Comment:
ok need to fix this based on
https://docs.oracle.com/en/java/javase/19/docs/specs/javadoc/doc-comment-spec.html
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gerlowskija commented on a diff in pull request #1115: Created V2 equivalent of REPLACENODE
gerlowskija commented on code in PR #1115:
URL: https://github.com/apache/solr/pull/1115#discussion_r1004888461
##
solr/core/src/java/org/apache/solr/handler/admin/api/ReplaceNodeAPI.java:
##
@@ -0,0 +1,119 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.handler.admin.api;
+
+import static
org.apache.solr.client.solrj.impl.BinaryResponseParser.BINARY_CONTENT_TYPE_V2;
+import static org.apache.solr.cloud.Overseer.QUEUE_OPERATION;
+import static org.apache.solr.common.params.CollectionParams.SOURCE_NODE;
+import static org.apache.solr.common.params.CollectionParams.TARGET_NODE;
+import static
org.apache.solr.handler.admin.CollectionsHandler.DEFAULT_COLLECTION_OP_TIMEOUT;
+import static
org.apache.solr.security.PermissionNameProvider.Name.COLL_EDIT_PERM;
+
+import com.fasterxml.jackson.annotation.JsonProperty;
+import io.swagger.v3.oas.annotations.Parameter;
+import io.swagger.v3.oas.annotations.media.Schema;
+import io.swagger.v3.oas.annotations.parameters.RequestBody;
+import java.util.HashMap;
+import java.util.Map;
+import javax.inject.Inject;
+import javax.ws.rs.POST;
+import javax.ws.rs.Path;
+import javax.ws.rs.PathParam;
+import javax.ws.rs.Produces;
+import org.apache.solr.client.solrj.SolrResponse;
+import org.apache.solr.common.cloud.ZkNodeProps;
+import org.apache.solr.common.params.CollectionParams;
+import org.apache.solr.common.params.CollectionParams.CollectionAction;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.handler.admin.CollectionsHandler;
+import org.apache.solr.jersey.JacksonReflectMapWriter;
+import org.apache.solr.jersey.PermissionName;
+import org.apache.solr.jersey.SolrJerseyResponse;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+
+/**
+ * V2 API for recreating replicas in one node (the source) on another node(s)
(the target).
+ *
+ * This API is analogous to the v1 /admin/collections?action=REPLACENODE
command.
+ */
+@Path("/nodes/{nodeName}/commands/replace/{targetNodeName}")
+public class ReplaceNodeAPI extends AdminAPIBase {
+
+ @Inject
+ public ReplaceNodeAPI(
+ CoreContainer coreContainer,
+ SolrQueryRequest solrQueryRequest,
+ SolrQueryResponse solrQueryResponse) {
+super(coreContainer, solrQueryRequest, solrQueryResponse);
+ }
+
+ @POST
+ @Produces({"application/json", "application/xml", BINARY_CONTENT_TYPE_V2})
+ @PermissionName(COLL_EDIT_PERM)
+ public SolrJerseyResponse replaceNode(
+ @Parameter(description = "The name of the node to be replaced.",
required = true)
+ @PathParam("nodeName")
+ String nodeName,
+ @Parameter(description = "The name of the new node.", required = true)
+ @PathParam("targetNodeName")
+ String targetNodeName,
+ @RequestBody(description = "The value of the targetNodeName", required =
true)
+ ReplaceNodeRequestBody requestBody)
+ throws Exception {
+final SolrJerseyResponse response =
instantiateJerseyResponse(SolrJerseyResponse.class);
+final CoreContainer coreContainer =
fetchAndValidateZooKeeperAwareCoreContainer();
+/** TODO Record node for log and tracing */
+final ZkNodeProps remoteMessage = createRemoteMessage(nodeName,
targetNodeName, requestBody);
+final SolrResponse remoteResponse =
+CollectionsHandler.submitCollectionApiCommand(
+coreContainer,
+coreContainer.getDistributedCollectionCommandRunner(),
+remoteMessage,
+CollectionParams.CollectionAction.REPLACENODE,
+DEFAULT_COLLECTION_OP_TIMEOUT);
+if (remoteResponse.getException() != null) {
+ throw remoteResponse.getException();
+}
+
+disableResponseCaching();
+return response;
+ }
+
+ public ZkNodeProps createRemoteMessage(
Review Comment:
[0] It looks like the [v1 codepath that created this
message](https://github.com/apache/solr/pull/1115/files#diff-582348d44491dcb0ce1dfb169fb544e9e95620b2d0448eb1a1744f4e8dd5a349L1794)
also passed through a `waitForFinalState` parameter.
Unless you had a particular reason for excluding this from your RequestBody
POJO below and from this message-crea
[jira] [Updated] (SOLR-16496) provide option for Query Elevation Component to bypass filters
[
https://issues.apache.org/jira/browse/SOLR-16496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rudi Seitz updated SOLR-16496:
--
Description:
The Query Elevation Component respects the fq parameter.
A document listed in elevate.xml or specified via the {{elevateIds}} parameter
must match the provided filter queries in order to be included in the result
set for a given query. Documents that don't match the filter queries will be
excluded regardless of whether they are supposed to be "elevated."
In some cases, this behavior is desirable; in other cases, it is not. For
example, an ecommerce landing page might filter products according to whether
they are in stock ({{{}fq=inStock:true{}}}) but might wish to show certain
promoted products regardless of inventory.
This ticket asks for an {{elevateFilteredDocs}} parameter that could be set to
true to include elevated documents in the result set regardless of whether they
match the provided filter queries. The default would be false, in accordance
with the current behavior.
This parameter would allow elevated documents to "bypass" the provided filters,
while keeping the filters in place for non-elevated documents.
>From an implementation standpoint, this parameter could be supported with code
>in {{QueryElevationComponent#setQuery}} that updates the filter queries in
>similar way to how the main query is updated. When
>{{{}elevateFilteredDocs=true{}}}, each filter query would become a boolean
>"OR" of the original filter query with a second query matching the elevated
>documents by id.
was:
The Query Elevation Component respects the fq parameter.
A document listed in elevate.xml or specified via the {{elevateIds}} parameter
must match the provided filter queries in order to be included in the result
set for a given query. Documents that don't match the filter queries will be
excluded regardless of whether they are supposed to be "elevated."
In some cases, this behavior is desirable; in other cases, it is not. For
example, an ecommerce landing page might filter products according to whether
they are in stock ({{{}fq=inStock:true{}}}) but might wish to show certain
promoted products regardless of inventory.
This ticket asks for an {{elevateFilteredDocuments}} parameter that could be
set to true to include elevated documents in the result set regardless of
whether they match the provided filter queries. The default would be false, in
accordance with the current behavior.
This parameter would allow elevated documents to "bypass" the provided filters,
while keeping the filters in place for non-elevated documents.
>From an implementation standpoint, this parameter could be supported with code
>in {{QueryElevationComponent#setQuery}} that updates the filter queries in
>similar way to how the main query is updated. When
>{{{}elevateFilteredDocuments=true{}}}, each filter query would become a
>boolean "OR" of the original filter query with a second query matching the
>elevated documents by id.
> provide option for Query Elevation Component to bypass filters
> --
>
> Key: SOLR-16496
> URL: https://issues.apache.org/jira/browse/SOLR-16496
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
>Reporter: Rudi Seitz
>Priority: Major
>
> The Query Elevation Component respects the fq parameter.
> A document listed in elevate.xml or specified via the {{elevateIds}}
> parameter must match the provided filter queries in order to be included in
> the result set for a given query. Documents that don't match the filter
> queries will be excluded regardless of whether they are supposed to be
> "elevated."
> In some cases, this behavior is desirable; in other cases, it is not. For
> example, an ecommerce landing page might filter products according to whether
> they are in stock ({{{}fq=inStock:true{}}}) but might wish to show certain
> promoted products regardless of inventory.
> This ticket asks for an {{elevateFilteredDocs}} parameter that could be set
> to true to include elevated documents in the result set regardless of whether
> they match the provided filter queries. The default would be false, in
> accordance with the current behavior.
> This parameter would allow elevated documents to "bypass" the provided
> filters, while keeping the filters in place for non-elevated documents.
> From an implementation standpoint, this parameter could be supported with
> code in {{QueryElevationComponent#setQuery}} that updates the filter queries
> in similar way to how the main query is updated. When
> {{{}elevateFilteredDocs=true{}}}, each filter query would become a boolean
> "OR" of the original filter query with a second
[jira] [Commented] (SOLR-16477) Collection RENAME api creates broken alias
[
https://issues.apache.org/jira/browse/SOLR-16477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624018#comment-17624018
]
Alex Deparvu commented on SOLR-16477:
-
good point [~krisden], I missed this on the bug report. should be updated now.
> Collection RENAME api creates broken alias
> --
>
> Key: SOLR-16477
> URL: https://issues.apache.org/jira/browse/SOLR-16477
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0, 8.11.2
>Reporter: Alex Deparvu
>Priority: Major
> Attachments: broken-alias.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Renaming a collection results in a broken alias (name as the source param)
> pointing to a non-existent collection (named as the target param).
> Steps to reproduce:
> * First create a new collection
> {noformat}
> bin/solr create -c films -s 2 -rf 2
> {noformat}
> * Second issue rename call
> {noformat}
> > curl -X POST
> > "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
> { "responseHeader":{ "status":0, "QTime":125}}
> {noformat}
>
> This will create an alias called 'films' pointing to a collection named
> 'morefilms', when it should be the other way around.
>
> {noformat}
> > curl -X GET http://localhost:8983/api/cluster/aliases
> {
> "responseHeader": {
> "status": 0,
> "QTime": 0
> },
> "aliases": {
> "films": "morefilms"
> },
> "properties": {}
> } {noformat}
>
> !broken-alias.png|height=250!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16496) provide option for Query Elevation Component to bypass filters
[
https://issues.apache.org/jira/browse/SOLR-16496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624016#comment-17624016
]
Rudi Seitz commented on SOLR-16496:
---
I've begun implementing this request here:
[https://github.com/rseitz/solr/tree/SOLR-16496]
> provide option for Query Elevation Component to bypass filters
> --
>
> Key: SOLR-16496
> URL: https://issues.apache.org/jira/browse/SOLR-16496
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SearchComponents - other
>Reporter: Rudi Seitz
>Priority: Major
>
> The Query Elevation Component respects the fq parameter.
> A document listed in elevate.xml or specified via the {{elevateIds}}
> parameter must match the provided filter queries in order to be included in
> the result set for a given query. Documents that don't match the filter
> queries will be excluded regardless of whether they are supposed to be
> "elevated."
> In some cases, this behavior is desirable; in other cases, it is not. For
> example, an ecommerce landing page might filter products according to whether
> they are in stock ({{{}fq=inStock:true{}}}) but might wish to show certain
> promoted products regardless of inventory.
> This ticket asks for an {{elevateFilteredDocuments}} parameter that could be
> set to true to include elevated documents in the result set regardless of
> whether they match the provided filter queries. The default would be false,
> in accordance with the current behavior.
> This parameter would allow elevated documents to "bypass" the provided
> filters, while keeping the filters in place for non-elevated documents.
> From an implementation standpoint, this parameter could be supported with
> code in {{QueryElevationComponent#setQuery}} that updates the filter queries
> in similar way to how the main query is updated. When
> {{{}elevateFilteredDocuments=true{}}}, each filter query would become a
> boolean "OR" of the original filter query with a second query matching the
> elevated documents by id.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16477) Collection RENAME api creates broken alias
[
https://issues.apache.org/jira/browse/SOLR-16477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated SOLR-16477:
Description:
Renaming a collection results in a broken alias (name as the source param)
pointing to a non-existent collection (named as the target param).
Steps to reproduce:
* First create a new collection
{noformat}
bin/solr create -c films -s 2 -rf 2
{noformat}
* Second issue rename call
{noformat}
> curl -X POST
> "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
{ "responseHeader":{ "status":0, "QTime":125}}
{noformat}
This will create an alias called 'films' pointing to a collection named
'morefilms', when it should be the other way around.
{noformat}
> curl -X GET http://localhost:8983/api/cluster/aliases
{
"responseHeader": {
"status": 0,
"QTime": 0
},
"aliases": {
"films": "morefilms"
},
"properties": {}
} {noformat}
!broken-alias.png|height=250!
was:
Renaming a collection results in a broken alias (name as the source param)
pointing to a non-existent collection (named as the target param).
Steps to reproduce:
* First create a new collection
{noformat}
bin/solr create -c films -s 2 -rf 2
{noformat}
* Second issue rename call
{noformat}
> curl -X POST
> "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
{ "responseHeader":{ "status":0, "QTime":125}}
{noformat}
This will create an alias called 'films' pointing to a collection named
'morefilms', when it should be the other way around.
{noformat}
> curl -X GET http://localhost:8983/api/cluster/aliases
{
"responseHeader": {
"status": 0,
"QTime": 0
},
"aliases": {
"films": "morefilms"
},
"properties": {}
} {noformat}
!broken-alias.png|height=150!
> Collection RENAME api creates broken alias
> --
>
> Key: SOLR-16477
> URL: https://issues.apache.org/jira/browse/SOLR-16477
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0, 8.11.2
>Reporter: Alex Deparvu
>Priority: Major
> Attachments: broken-alias.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Renaming a collection results in a broken alias (name as the source param)
> pointing to a non-existent collection (named as the target param).
> Steps to reproduce:
> * First create a new collection
> {noformat}
> bin/solr create -c films -s 2 -rf 2
> {noformat}
> * Second issue rename call
> {noformat}
> > curl -X POST
> > "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
> { "responseHeader":{ "status":0, "QTime":125}}
> {noformat}
>
> This will create an alias called 'films' pointing to a collection named
> 'morefilms', when it should be the other way around.
>
> {noformat}
> > curl -X GET http://localhost:8983/api/cluster/aliases
> {
> "responseHeader": {
> "status": 0,
> "QTime": 0
> },
> "aliases": {
> "films": "morefilms"
> },
> "properties": {}
> } {noformat}
>
> !broken-alias.png|height=250!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16477) Collection RENAME api creates broken alias
[
https://issues.apache.org/jira/browse/SOLR-16477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated SOLR-16477:
Description:
Renaming a collection results in a broken alias (name as the source param)
pointing to a non-existent collection (named as the target param).
Steps to reproduce:
* First create a new collection
{noformat}
bin/solr create -c films -s 2 -rf 2
{noformat}
* Second issue rename call
{noformat}
> curl -X POST
> "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
{ "responseHeader":{ "status":0, "QTime":125}}
{noformat}
This will create an alias called 'films' pointing to a collection named
'morefilms', when it should be the other way around.
{noformat}
> curl -X GET http://localhost:8983/api/cluster/aliases
{
"responseHeader": {
"status": 0,
"QTime": 0
},
"aliases": {
"films": "morefilms"
},
"properties": {}
} {noformat}
!broken-alias.png|height=150!
was:
Renaming a collection results in a broken alias (name as the source param)
pointing to a non-existent collection (named as the target param).
Steps to reproduce:
* First create a new collection
{noformat}
bin/solr create -c films -s 2 -rf 2
{noformat}
* Second issue rename call
{noformat}
> curl -X POST
> "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
{ "responseHeader":{ "status":0, "QTime":125}}
{noformat}
This will create an alias called 'films' pointing to a collection named
'morefilms', when it should be the other way around.
{noformat}
> curl -X GET http://localhost:8983/api/cluster/aliases
{
"responseHeader": {
"status": 0,
"QTime": 0
},
"aliases": {
"films": "morefilms"
},
"properties": {}
} {noformat}
> Collection RENAME api creates broken alias
> --
>
> Key: SOLR-16477
> URL: https://issues.apache.org/jira/browse/SOLR-16477
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0, 8.11.2
>Reporter: Alex Deparvu
>Priority: Major
> Attachments: broken-alias.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Renaming a collection results in a broken alias (name as the source param)
> pointing to a non-existent collection (named as the target param).
> Steps to reproduce:
> * First create a new collection
> {noformat}
> bin/solr create -c films -s 2 -rf 2
> {noformat}
> * Second issue rename call
> {noformat}
> > curl -X POST
> > "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
> { "responseHeader":{ "status":0, "QTime":125}}
> {noformat}
>
> This will create an alias called 'films' pointing to a collection named
> 'morefilms', when it should be the other way around.
>
> {noformat}
> > curl -X GET http://localhost:8983/api/cluster/aliases
> {
> "responseHeader": {
> "status": 0,
> "QTime": 0
> },
> "aliases": {
> "films": "morefilms"
> },
> "properties": {}
> } {noformat}
>
> !broken-alias.png|height=150!
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16477) Collection RENAME api creates broken alias
[
https://issues.apache.org/jira/browse/SOLR-16477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated SOLR-16477:
Attachment: broken-alias.png
> Collection RENAME api creates broken alias
> --
>
> Key: SOLR-16477
> URL: https://issues.apache.org/jira/browse/SOLR-16477
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0, 8.11.2
>Reporter: Alex Deparvu
>Priority: Major
> Attachments: broken-alias.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Renaming a collection results in a broken alias (name as the source param)
> pointing to a non-existent collection (named as the target param).
> Steps to reproduce:
> * First create a new collection
> {noformat}
> bin/solr create -c films -s 2 -rf 2
> {noformat}
> * Second issue rename call
> {noformat}
> > curl -X POST
> > "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
> { "responseHeader":{ "status":0, "QTime":125}}
> {noformat}
>
> This will create an alias called 'films' pointing to a collection named
> 'morefilms', when it should be the other way around.
>
> {noformat}
> > curl -X GET http://localhost:8983/api/cluster/aliases
> {
> "responseHeader": {
> "status": 0,
> "QTime": 0
> },
> "aliases": {
> "films": "morefilms"
> },
> "properties": {}
> } {noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16477) Collection RENAME api creates broken alias
[
https://issues.apache.org/jira/browse/SOLR-16477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Deparvu updated SOLR-16477:
Description:
Renaming a collection results in a broken alias (name as the source param)
pointing to a non-existent collection (named as the target param).
Steps to reproduce:
* First create a new collection
{noformat}
bin/solr create -c films -s 2 -rf 2
{noformat}
* Second issue rename call
{noformat}
> curl -X POST
> "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
{ "responseHeader":{ "status":0, "QTime":125}}
{noformat}
This will create an alias called 'films' pointing to a collection named
'morefilms', when it should be the other way around.
{noformat}
> curl -X GET http://localhost:8983/api/cluster/aliases
{
"responseHeader": {
"status": 0,
"QTime": 0
},
"aliases": {
"films": "morefilms"
},
"properties": {}
} {noformat}
was:
Renaming a collection results in a broken alias (name as the source param)
pointing to a non-existent collection (named as the target param).
Steps to reproduce:
* First create a new collection
{noformat}
bin/solr create -c films -s 2 -rf 2
{noformat}
* Second issue rename call
{noformat}
> curl -X POST
> "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
{ "responseHeader":{ "status":0, "QTime":125}}
{noformat}
This will create an alias called 'films' pointing to a collection named
'morefilms', when it should be the other way around.
> Collection RENAME api creates broken alias
> --
>
> Key: SOLR-16477
> URL: https://issues.apache.org/jira/browse/SOLR-16477
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0, 8.11.2
>Reporter: Alex Deparvu
>Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Renaming a collection results in a broken alias (name as the source param)
> pointing to a non-existent collection (named as the target param).
> Steps to reproduce:
> * First create a new collection
> {noformat}
> bin/solr create -c films -s 2 -rf 2
> {noformat}
> * Second issue rename call
> {noformat}
> > curl -X POST
> > "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
> { "responseHeader":{ "status":0, "QTime":125}}
> {noformat}
>
> This will create an alias called 'films' pointing to a collection named
> 'morefilms', when it should be the other way around.
>
> {noformat}
> > curl -X GET http://localhost:8983/api/cluster/aliases
> {
> "responseHeader": {
> "status": 0,
> "QTime": 0
> },
> "aliases": {
> "films": "morefilms"
> },
> "properties": {}
> } {noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk opened a new pull request, #1128: SOLR-16427: Evaluate and fix errorprone rules - part 4
risdenk opened a new pull request, #1128: URL: https://github.com/apache/solr/pull/1128 https://issues.apache.org/jira/browse/SOLR-16427 builds on https://github.com/apache/solr/pull/1116 Enables the following errorprone rules: * TODO -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-16496) provide option for Query Elevation Component to bypass filters
Rudi Seitz created SOLR-16496:
-
Summary: provide option for Query Elevation Component to bypass
filters
Key: SOLR-16496
URL: https://issues.apache.org/jira/browse/SOLR-16496
Project: Solr
Issue Type: Improvement
Security Level: Public (Default Security Level. Issues are Public)
Components: SearchComponents - other
Reporter: Rudi Seitz
The Query Elevation Component respects the fq parameter.
A document listed in elevate.xml or specified via the {{elevateIds}} parameter
must match the provided filter queries in order to be included in the result
set for a given query. Documents that don't match the filter queries will be
excluded regardless of whether they are supposed to be "elevated."
In some cases, this behavior is desirable; in other cases, it is not. For
example, an ecommerce landing page might filter products according to whether
they are in stock ({{{}fq=inStock:true{}}}) but might wish to show certain
promoted products regardless of inventory.
This ticket asks for an {{elevateFilteredDocuments}} parameter that could be
set to true to include elevated documents in the result set regardless of
whether they match the provided filter queries. The default would be false, in
accordance with the current behavior.
This parameter would allow elevated documents to "bypass" the provided filters,
while keeping the filters in place for non-elevated documents.
>From an implementation standpoint, this parameter could be supported with code
>in {{QueryElevationComponent#setQuery}} that updates the filter queries in
>similar way to how the main query is updated. When
>{{{}elevateFilteredDocuments=true{}}}, each filter query would become a
>boolean "OR" of the original filter query with a second query matching the
>elevated documents by id.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] stillalex commented on pull request #1127: SOLR-16477 Collection RENAME api creates broken alias
stillalex commented on PR #1127:
URL: https://github.com/apache/solr/pull/1127#issuecomment-1291056422
There is some code in the Aliases class I don't get:
```
public static Map>
convertMapOfCommaDelimitedToMapOfList(
Map collectionAliasMap) {
return collectionAliasMap.entrySet().stream()
.collect(
Collectors.toMap(
Map.Entry::getKey,
e -> splitCollections(e.getValue()),
(a, b) -> {
throw new IllegalStateException(
String.format(Locale.ROOT, "Duplicate key %s", b));
},
LinkedHashMap::new));
}
```
if the starting point for the stream is a `Map<>`, the 'merge keys' part
where it checks for collisions`(a, b) -> IllegalStateException` would never be
possible, as the keys are already guaranteed to be unique by the map contract.
am I reading this wrong?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] stillalex commented on pull request #1127: SOLR-16477 Collection RENAME api creates broken alias
stillalex commented on PR #1127: URL: https://github.com/apache/solr/pull/1127#issuecomment-1291053356 thanks for taking a look @risdenk! updated PR based on your observations so far. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] stillalex commented on a diff in pull request #1127: SOLR-16477 Collection RENAME api creates broken alias
stillalex commented on code in PR #1127: URL: https://github.com/apache/solr/pull/1127#discussion_r1004897653 ## solr/CHANGES.txt: ## @@ -65,6 +65,8 @@ Optimizations Bug Fixes - +* SOLR-16477: Collection RENAME api creates broken alias Review Comment: moved it to the bottom -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #1116: SOLR-16427: Evaluate and fix errorprone rules - part 3
risdenk commented on code in PR #1116:
URL: https://github.com/apache/solr/pull/1116#discussion_r1004894002
##
solr/core/src/java/org/apache/solr/util/hll/SerializationUtil.java:
##
@@ -137,8 +137,8 @@ public static byte packVersionByte(final int schemaVersion,
final int typeOrdina
*
* If 'explicit-disabled' is chosen, this value should be
0.
* If 'auto' is chosen, this value should be 63.
- * If a cutoff of 2n is desired, for 0 <= n <
31, this value
- * should be n + 1.
+ * If a cutoff of 2n is desired, for {@code 0 <=
n < 31}, this
+ * value should be {@code n + 1}.
Review Comment:
so I went back and forth on this a bunch. I need to look at the actual
generated javadoc to see what it looks like. Will check 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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16477) Collection RENAME api creates broken alias
[
https://issues.apache.org/jira/browse/SOLR-16477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624002#comment-17624002
]
Kevin Risden commented on SOLR-16477:
-
[~stillalex] can you add to the description potentially 2 things to show how
this is failing:
* the aliases list showing films pointing to morefilms - something like `curl
-X GET http://localhost:8983/api/cluster/aliases`
* potentially a select command showing the query failing? something like `curl
-X GET http://localhost:8983/solr/morefilms/select?q=*:*`
ideally these would both show the issue - since right now the descriptions
shared all have status=0 so no detail showing the actual failure.
> Collection RENAME api creates broken alias
> --
>
> Key: SOLR-16477
> URL: https://issues.apache.org/jira/browse/SOLR-16477
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0, 8.11.2
>Reporter: Alex Deparvu
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Renaming a collection results in a broken alias (name as the source param)
> pointing to a non-existent collection (named as the target param).
> Steps to reproduce:
> * First create a new collection
> {noformat}
> bin/solr create -c films -s 2 -rf 2
> {noformat}
> * Second issue rename call
> {noformat}
> > curl -X POST
> > "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
> { "responseHeader":{ "status":0, "QTime":125}}
> {noformat}
>
> This will create an alias called 'films' pointing to a collection named
> 'morefilms', when it should be the other way around.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16477) Collection RENAME api creates broken alias
[
https://issues.apache.org/jira/browse/SOLR-16477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16477:
Status: Patch Available (was: Open)
> Collection RENAME api creates broken alias
> --
>
> Key: SOLR-16477
> URL: https://issues.apache.org/jira/browse/SOLR-16477
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0, 8.11.2
>Reporter: Alex Deparvu
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Renaming a collection results in a broken alias (name as the source param)
> pointing to a non-existent collection (named as the target param).
> Steps to reproduce:
> * First create a new collection
> {noformat}
> bin/solr create -c films -s 2 -rf 2
> {noformat}
> * Second issue rename call
> {noformat}
> > curl -X POST
> > "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
> { "responseHeader":{ "status":0, "QTime":125}}
> {noformat}
>
> This will create an alias called 'films' pointing to a collection named
> 'morefilms', when it should be the other way around.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on a diff in pull request #1127: SOLR-16477 Collection RENAME api creates broken alias
risdenk commented on code in PR #1127:
URL: https://github.com/apache/solr/pull/1127#discussion_r1004878560
##
solr/solrj/src/test/org/apache/solr/common/cloud/AliasesTest.java:
##
@@ -0,0 +1,84 @@
+/*
+ * 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.common.cloud;
+
+import java.util.List;
+import java.util.Map;
+import org.apache.solr.SolrTestCase;
+import org.apache.solr.common.SolrException;
+
+/** Unit test for {@link Aliases} */
+public class AliasesTest extends SolrTestCase {
+
+ public void testCloneWithRenameNullBefore() {
+Aliases aliases = Aliases.EMPTY;
+try {
+ aliases.cloneWithRename(null, "alias1");
Review Comment:
`assertThrows` would be better for this test?
##
solr/solrj/src/test/org/apache/solr/common/cloud/AliasesTest.java:
##
@@ -0,0 +1,84 @@
+/*
+ * 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.common.cloud;
+
+import java.util.List;
+import java.util.Map;
+import org.apache.solr.SolrTestCase;
+import org.apache.solr.common.SolrException;
+
+/** Unit test for {@link Aliases} */
+public class AliasesTest extends SolrTestCase {
+
+ public void testCloneWithRenameNullBefore() {
+Aliases aliases = Aliases.EMPTY;
+try {
+ aliases.cloneWithRename(null, "alias1");
+ fail("null value should not be allowed");
+} catch (SolrException e) {
+ assertEquals(SolrException.ErrorCode.BAD_REQUEST.code, e.code());
+}
+ }
+
+ public void testCloneWithRenameEmptyBefore() {
+Aliases aliases = Aliases.EMPTY;
+try {
+ aliases.cloneWithRename("", "alias1");
+ fail("null value should not be allowed");
+} catch (SolrException e) {
+ assertEquals(SolrException.ErrorCode.BAD_REQUEST.code, e.code());
+}
+ }
+
+ public void testCloneWithRenameEmptyAfter() {
+Aliases aliases = Aliases.EMPTY;
+try {
+ aliases.cloneWithRename("alias0", "");
+ fail("null value should not be allowed");
+} catch (SolrException e) {
Review Comment:
`assertThrows` would be better for this test?
##
solr/CHANGES.txt:
##
@@ -65,6 +65,8 @@ Optimizations
Bug Fixes
-
+* SOLR-16477: Collection RENAME api creates broken alias
Review Comment:
nit: usually this goes at the bottom of the list.
##
solr/solrj/src/test/org/apache/solr/common/cloud/AliasesTest.java:
##
@@ -0,0 +1,84 @@
+/*
+ * 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.common.cloud;
+
+import java.util.List;
+import java.util.Map;
+import org.apache.solr.SolrTestCase;
+import org.apache.solr.common.SolrException;
+
+/** Unit test for {@link Aliases} */
[jira] [Commented] (SOLR-16477) Collection RENAME api creates broken alias
[
https://issues.apache.org/jira/browse/SOLR-16477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623996#comment-17623996
]
Alex Deparvu commented on SOLR-16477:
-
I was able to repro this bug via SolrJ client too
{code:java}
SolrClient client = getSolrClient();
SolrRequest request = new CollectionAdminRequest.Rename("films", "morefilms");
NamedList response = client.request(request);
System.out.println(response); {code}
response
{noformat}
{responseHeader={status=0, QTime=128}} {noformat}
behavior is the same, you are getting an alias called 'films' pointing to a
broken collection names 'morefilms'
> Collection RENAME api creates broken alias
> --
>
> Key: SOLR-16477
> URL: https://issues.apache.org/jira/browse/SOLR-16477
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0, 8.11.2
>Reporter: Alex Deparvu
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Renaming a collection results in a broken alias (name as the source param)
> pointing to a non-existent collection (named as the target param).
> Steps to reproduce:
> * First create a new collection
> {noformat}
> bin/solr create -c films -s 2 -rf 2
> {noformat}
> * Second issue rename call
> {noformat}
> > curl -X POST
> > "http://127.0.0.1:8983/solr/admin/collections?action=RENAME&name=films&target=morefilms";
> { "responseHeader":{ "status":0, "QTime":125}}
> {noformat}
>
> This will create an alias called 'films' pointing to a collection named
> 'morefilms', when it should be the other way around.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Assigned] (SOLR-16495) Update first page of ref guide ("Introduction to Solr")
[
https://issues.apache.org/jira/browse/SOLR-16495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gus Heck reassigned SOLR-16495:
---
Assignee: Gus Heck
> Update first page of ref guide ("Introduction to Solr")
> ---
>
> Key: SOLR-16495
> URL: https://issues.apache.org/jira/browse/SOLR-16495
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: documentation
>Affects Versions: 9.0, main (10.0)
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Minor
>
> I happened to read this page in the ref guide the other day, and found it to
> be inconsistently voiced, and simultaneously under and over selling Solr. I
> intend to submit a PR with a suggested update with the goal of a more
> consistent flow, more links and a more carefully worded 10,000ft view of
> Solr.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Created] (SOLR-16495) Update first page of ref guide ("Introduction to Solr")
Gus Heck created SOLR-16495:
---
Summary: Update first page of ref guide ("Introduction to Solr")
Key: SOLR-16495
URL: https://issues.apache.org/jira/browse/SOLR-16495
Project: Solr
Issue Type: Task
Security Level: Public (Default Security Level. Issues are Public)
Components: documentation
Affects Versions: 9.0, main (10.0)
Reporter: Gus Heck
I happened to read this page in the ref guide the other day, and found it to be
inconsistently voiced, and simultaneously under and over selling Solr. I intend
to submit a PR with a suggested update with the goal of a more consistent flow,
more links and a more carefully worded 10,000ft view of Solr.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] stillalex opened a new pull request, #1127: SOLR-16477 Collection RENAME api creates broken alias
stillalex opened a new pull request, #1127: URL: https://github.com/apache/solr/pull/1127 https://issues.apache.org/jira/browse/SOLR-16477 # Description Collection RENAME api creates broken alias, named as source pointing to collection named as target. # Solution Revert params to create alias as 'target' pointing to source collection. # Tests Unit tests for Aliases class covering the rename. I had a look at a failing test under CollectionsAPISolrJTest and had to tweak the assertions a bit, would really appreciate some input if the changes make sense or not. Just to add to this, I'm currently not sure if a client going through SolrJ can issue a rename which has a different path than the api I changed, where the expectation is different, or this test is just emulating the code as it was written and effectively mirroring the bug. # Checklist Please review the following and check all that apply: - [ ] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [ ] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [ ] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] HoustonPutman commented on pull request #1125: Fix useGpg signing without password
HoustonPutman commented on PR #1125: URL: https://github.com/apache/solr/pull/1125#issuecomment-1290977959 The new releaseWizard step should allow it to work for almost all environments. So you can go back to running it through the releaseWizard after this is merged. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623976#comment-17623976 ] Kevin Risden commented on SOLR-16441: - FWIW I looked at this a bit. The biggest question will be do the dependencies we care about support Jetty 11 * dropwizard metrics-jetty11 exists - https://mvnrepository.com/artifact/io.dropwizard.metrics/metrics-jetty11 * need to check s3mock? https://mvnrepository.com/artifact/com.adobe.testing/s3mock-junit4/2.8.0 * need to check Hadoop integration w/ servlet stuff? Some potentially useful references: * https://www.eclipse.org/community/eclipse_newsletter/2020/november/1.php * https://github.com/jjohannes/java-ecosystem-capabilities * https://github.com/ljacomet/logging-capabilities > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > > Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in > SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to > jakarta namespace for servlet. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16441: Component/s: Server > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: Server >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > > Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in > SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to > jakarta namespace for servlet. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Risden updated SOLR-16441: Description: Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to jakarta namespace for servlet. was: Solr is currently using Jetty 9.4.x, which is now out of community support, we should upgrade to Jetty 11 or at least 10. > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > > Solr is currently using Jetty 9.4.x and upgrading to Jetty 10.x in > SOLR-15955, we should look at upgrade to Jetty 11 which moves from javax to > jakarta namespace for servlet. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612729#comment-17612729 ] Kevin Risden edited comment on SOLR-16441 at 10/25/22 6:22 PM: --- Jetty 10 upgrade is SOLR-15955 and is most of the way done. was (Author: risdenk): Duplicate or related to SOLR-15955 - there is a pr out there for the upgrade > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > > Solr is currently using Jetty 9.4.x, which is now out of community support, > we should upgrade to Jetty 11 or at least 10. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16494) jetty 11 http client
[
https://issues.apache.org/jira/browse/SOLR-16494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623972#comment-17623972
]
Kevin Risden commented on SOLR-16494:
-
The other thing I'll add here about a separate Jetty 11.x client - the way the
Solr build system works today is to standardize dependencies across the
project. This means its hard today to have different dependency versions in a
single module separate - so not easy to just build a Jetty 11.x Solr client.
> jetty 11 http client
>
>
> Key: SOLR-16494
> URL: https://issues.apache.org/jira/browse/SOLR-16494
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.0
>Reporter: Bernd Wahlen
>Priority: Minor
>
> i tried to migrate one of our smaller projects to spring boot3 rc1 and the
> only issue was with solr. Solr uses jetty9 and spring boot3 provides jetty11,
> the method used in the solr Http2SolrClient was (re)moved in jetty11. Since
> solr9 already requires java11, it should be possible to update or build a
> seperate solrj or httpclient using jetty11 or factor out to pluggable http
> client with different implementations.
> btw: jetty9 is eol
> https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.48.v20220622
> {code:java}
> An attempt was made to call a method that does not exist. The attempt was
> made from the following location:
>
> org.apache.solr.client.solrj.impl.Http2SolrClient.createHttpClient(Http2SolrClient.java:227)
> The following method did not exist:
> 'void
> org.eclipse.jetty.client.HttpClient.(org.eclipse.jetty.client.HttpClientTransport,
> org.eclipse.jetty.util.ssl.SslContextFactory)'
> The calling method's class,
> org.apache.solr.client.solrj.impl.Http2SolrClient, was loaded from the
> following location:
>
> jar:file:/projects/local/photoai/photomoderation-1.0.0.jar!/BOOT-INF/lib/solr-solrj-9.0.0.jar!/org/apache/solr/client/solrj/impl/Http2SolrClient.class
> The called method's class, org.eclipse.jetty.client.HttpClient, is available
> from the following locations:
>
> jar:file:/projects/local/photoai/photomoderation-1.0.0.jar!/BOOT-INF/lib/jetty-client-11.0.12.jar!/org/eclipse/jetty/client/HttpClient.class
> The called method's class hierarchy was loaded from the following locations:
> org.eclipse.jetty.client.HttpClient:
> jar:file:/projects/local/photoai/photomoderation-1.0.0.jar!/BOOT-INF/lib/jetty-client-11.0.12.jar!/
> org.eclipse.jetty.util.component.ContainerLifeCycle:
> jar:file:/projects/local/photoai/photomoderation-1.0.0.jar!/BOOT-INF/lib/jetty-util-11.0.12.jar!/
> org.eclipse.jetty.util.component.AbstractLifeCycle:
> jar:file:/projects/local/photoai/photomoderation-1.0.0.jar!/BOOT-INF/lib/jetty-util-11.0.12.jar!/
> Action:
> Correct the classpath of your application so that it contains compatible
> versions of the classes org.apache.solr.client.solrj.impl.Http2SolrClient and
> org.eclipse.jetty.client.HttpClient
> (main)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] (SOLR-16441) Upgrade Jetty to 11.x
[ https://issues.apache.org/jira/browse/SOLR-16441 ] Kevin Risden deleted comment on SOLR-16441: - was (Author: risdenk): Jetty 10 upgrade is SOLR-15955 and is most of the way done. > Upgrade Jetty to 11.x > - > > Key: SOLR-16441 > URL: https://issues.apache.org/jira/browse/SOLR-16441 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Tomas Eduardo Fernandez Lobbe >Priority: Major > > Solr is currently using Jetty 9.4.x, which is now out of community support, > we should upgrade to Jetty 11 or at least 10. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-11028) Create a v2 API equivalent for REPLACENODE API
[ https://issues.apache.org/jira/browse/SOLR-11028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623971#comment-17623971 ] Joshua Ouma commented on SOLR-11028: I found the solution after some critical analysis > Create a v2 API equivalent for REPLACENODE API > -- > > Key: SOLR-11028 > URL: https://issues.apache.org/jira/browse/SOLR-11028 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud, v2 API >Reporter: Shalin Shekhar Mangar >Priority: Major > > The REPLACENODE API is only implemented as part of the v1 collections API. > There should be an equivalent call in the v2 paradigm. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] gerlowskija commented on a diff in pull request #1115: Created V2 equivalent of REPLACENODE
gerlowskija commented on code in PR #1115:
URL: https://github.com/apache/solr/pull/1115#discussion_r1004828107
##
solr/core/src/java/org/apache/solr/handler/admin/api/ReplaceNodeAPI.java:
##
@@ -0,0 +1,121 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.handler.admin.api;
+
+import static
org.apache.solr.client.solrj.impl.BinaryResponseParser.BINARY_CONTENT_TYPE_V2;
+import static org.apache.solr.cloud.Overseer.QUEUE_OPERATION;
+import static org.apache.solr.common.cloud.ZkStateReader.NODE_NAME_PROP;
+import static org.apache.solr.common.cloud.ZkStateReader.PROPERTY_VALUE_PROP;
+import static org.apache.solr.common.cloud.ZkStateReader.TARGET_NODE_NAME_PROP;
+import static
org.apache.solr.handler.admin.CollectionsHandler.DEFAULT_COLLECTION_OP_TIMEOUT;
+import static
org.apache.solr.security.PermissionNameProvider.Name.COLL_EDIT_PERM;
+
+import com.fasterxml.jackson.annotation.JsonProperty;
+import io.swagger.v3.oas.annotations.Parameter;
+import io.swagger.v3.oas.annotations.media.Schema;
+import io.swagger.v3.oas.annotations.parameters.RequestBody;
+import java.util.HashMap;
+import java.util.Map;
+import javax.inject.Inject;
+import javax.ws.rs.POST;
+import javax.ws.rs.Path;
+import javax.ws.rs.PathParam;
+import javax.ws.rs.Produces;
+import org.apache.solr.client.solrj.SolrResponse;
+import org.apache.solr.common.cloud.ZkNodeProps;
+import org.apache.solr.common.params.CollectionParams;
+import org.apache.solr.common.params.CollectionParams.CollectionAction;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.handler.admin.CollectionsHandler;
+import org.apache.solr.jersey.JacksonReflectMapWriter;
+import org.apache.solr.jersey.PermissionName;
+import org.apache.solr.jersey.SolrJerseyResponse;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+
+/**
+ * V2 API for recreating replicas in one node (the source) on another node(s)
(the target).
+ *
+ * This API is analogous to the v1 /admin/collections?action=REPLACENODE
command.
+ */
+@Path("/nodes/{nodeName}/commands/replace/{targetNodeName}")
Review Comment:
**TL;DR** I like Noble's suggestion to switch to
`/cluster/nodes/nodeName/...`. I'd say go with that unless you have any
objections Josh?
Additional Context:
Yeah, I pointed Josh at the v2 API syntax proposed in that spreadsheet.
There was some debate there about how to handle this and other "node related"
APIs. In particular we struggled to come up with a syntax that made sense for
Solr's weird mix of node-local (e.g. the v1 `/admin/info/logging`) and truly
distributed (`/admin/collections?action=REPLACENODE`) APIs related to nodes.
See the previous discussion
[here](https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?disco=bSSbh5M).
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] madrob commented on a diff in pull request #1116: SOLR-16427: Evaluate and fix errorprone rules - part 3
madrob commented on code in PR #1116:
URL: https://github.com/apache/solr/pull/1116#discussion_r1004825708
##
solr/core/src/java/org/apache/solr/util/hll/SerializationUtil.java:
##
@@ -137,8 +137,8 @@ public static byte packVersionByte(final int schemaVersion,
final int typeOrdina
*
* If 'explicit-disabled' is chosen, this value should be
0.
* If 'auto' is chosen, this value should be 63.
- * If a cutoff of 2n is desired, for 0 <= n <
31, this value
- * should be n + 1.
+ * If a cutoff of 2n is desired, for {@code 0 <=
n < 31}, this
+ * value should be {@code n + 1}.
Review Comment:
Duplicate code tags?
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] iamsanjay commented on a diff in pull request #1119: [SOLR-16461] Create v2 equivalent of v1 ReplicationHandler 'BACKUP'
iamsanjay commented on code in PR #1119:
URL: https://github.com/apache/solr/pull/1119#discussion_r1004820977
##
solr/core/src/java/org/apache/solr/handler/replication/BackupAPI.java:
##
@@ -0,0 +1,100 @@
+package org.apache.solr.handler.replication;
+
+import static org.apache.solr.handler.ClusterAPI.wrapParams;
+import static
org.apache.solr.security.PermissionNameProvider.Name.CORE_EDIT_PERM;
+
+import io.swagger.v3.oas.annotations.Operation;
+import io.swagger.v3.oas.annotations.media.Schema;
+import io.swagger.v3.oas.annotations.parameters.RequestBody;
+import java.util.HashMap;
+import java.util.Map;
+import javax.inject.Inject;
+import javax.ws.rs.POST;
+import javax.ws.rs.Path;
+import javax.ws.rs.PathParam;
+import javax.ws.rs.Produces;
+import javax.ws.rs.core.MediaType;
+import org.apache.solr.api.JerseyResource;
+import org.apache.solr.common.annotation.JsonProperty;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.handler.ReplicationHandler;
+import org.apache.solr.jersey.JacksonReflectMapWriter;
+import org.apache.solr.jersey.PermissionName;
+import org.apache.solr.jersey.SolrJerseyResponse;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+
+/** V2 endpoint for Backup API used for User-Managed clusters and Single-Node
Installation. */
+@Path("/cores/{cores}/replication/backups")
+public class BackupAPI extends JerseyResource {
Review Comment:
I have created new package for it and named it 'replication' under 'handler'
package. And I was thinking of moving all the replication related commands
under this package.
But if we do not want new package then Yes I can change it's name to
suggested name and move it to /handler/admin/api
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-16462) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)
[ https://issues.apache.org/jira/browse/SOLR-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623963#comment-17623963 ] John Durham edited comment on SOLR-16462 at 10/25/22 6:09 PM: -- Sure thing! The PR should be available here: [https://github.com/apache/solr/pull/1126]. I spent a little bit of time thinking through how to make the async handling code usable by both the original V1 flow and the new V2 resources, but I haven't found a solution yet (at least not a convoluted one). was (Author: jdurham): Sure thing! The PR should be available [here|[https://github.com/apache/solr/pull/1126].] I spent a little bit of time thinking through how to make the async handling code usable by both the original V1 flow and the new V2 resources, but I haven't found a solution yet (at least not a convoluted one). > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (core level) > -- > > Key: SOLR-16462 > URL: https://issues.apache.org/jira/browse/SOLR-16462 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.1 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > Time Spent: 10m > Remaining Estimate: 0h > > Snapshot API has no v2 equivalent. This ticket is to track changes made to > the Solr to add v2 equivalent of 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' api. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16462) Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)
[ https://issues.apache.org/jira/browse/SOLR-16462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623963#comment-17623963 ] John Durham commented on SOLR-16462: Sure thing! The PR should be available [here|[https://github.com/apache/solr/pull/1126].] I spent a little bit of time thinking through how to make the async handling code usable by both the original V1 flow and the new V2 resources, but I haven't found a solution yet (at least not a convoluted one). > Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' (core level) > -- > > Key: SOLR-16462 > URL: https://issues.apache.org/jira/browse/SOLR-16462 > Project: Solr > Issue Type: Sub-task > Components: v2 API >Affects Versions: 9.1 >Reporter: Sanjay Dutt >Priority: Major > Labels: V2, newdev > Time Spent: 10m > Remaining Estimate: 0h > > Snapshot API has no v2 equivalent. This ticket is to track changes made to > the Solr to add v2 equivalent of 'CREATESNAPSHOT', 'LISTSNAPSHOT' and > 'DELETESNAPSHOT' api. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] iamsanjay commented on a diff in pull request #1119: [SOLR-16461] Create v2 equivalent of v1 ReplicationHandler 'BACKUP'
iamsanjay commented on code in PR #1119:
URL: https://github.com/apache/solr/pull/1119#discussion_r1004818754
##
solr/core/src/java/org/apache/solr/handler/replication/BackupAPI.java:
##
@@ -0,0 +1,100 @@
+package org.apache.solr.handler.replication;
+
+import static org.apache.solr.handler.ClusterAPI.wrapParams;
+import static
org.apache.solr.security.PermissionNameProvider.Name.CORE_EDIT_PERM;
+
+import io.swagger.v3.oas.annotations.Operation;
+import io.swagger.v3.oas.annotations.media.Schema;
+import io.swagger.v3.oas.annotations.parameters.RequestBody;
+import java.util.HashMap;
+import java.util.Map;
+import javax.inject.Inject;
+import javax.ws.rs.POST;
+import javax.ws.rs.Path;
+import javax.ws.rs.PathParam;
+import javax.ws.rs.Produces;
+import javax.ws.rs.core.MediaType;
+import org.apache.solr.api.JerseyResource;
+import org.apache.solr.common.annotation.JsonProperty;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.handler.ReplicationHandler;
+import org.apache.solr.jersey.JacksonReflectMapWriter;
+import org.apache.solr.jersey.PermissionName;
+import org.apache.solr.jersey.SolrJerseyResponse;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+
+/** V2 endpoint for Backup API used for User-Managed clusters and Single-Node
Installation. */
+@Path("/cores/{cores}/replication/backups")
+public class BackupAPI extends JerseyResource {
+ private final SolrQueryRequest solrQueryRequest;
+ private final SolrQueryResponse solrQueryResponse;
+ private final ReplicationHandler replicationHandler;
+
+ @PathParam("cores")
+ private String coreName;
+
+ @Inject
+ public BackupAPI(
+ CoreContainer cc, SolrQueryRequest solrQueryRequest, SolrQueryResponse
solrQueryResponse) {
+this.replicationHandler =
+(ReplicationHandler)
cc.getCore(coreName).getRequestHandler(ReplicationHandler.PATH);
Review Comment:
Now moving on to the other thing which is to move the replicationHandler
code to API's. I am just curious If we move code to API's. How we are going to
access this below configuration? I will try to run the backup command via
JAS-RX API and see if I still have access to them.
```
optimize
optimize
schema.xml,stopwords.txt,elevate.xml
2
00:00:10
16
```
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] chatman commented on pull request #1125: Fix useGpg signing without password
chatman commented on PR #1125: URL: https://github.com/apache/solr/pull/1125#issuecomment-1290954867 Thanks Houston, I'm trying this out with a new run of RC1. Might take an hour or so before I get to know if it works. If it works, I'll merge to branch_9x and main. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] iamsanjay commented on a diff in pull request #1119: [SOLR-16461] Create v2 equivalent of v1 ReplicationHandler 'BACKUP'
iamsanjay commented on code in PR #1119:
URL: https://github.com/apache/solr/pull/1119#discussion_r1004816133
##
solr/core/src/java/org/apache/solr/handler/replication/BackupAPI.java:
##
@@ -0,0 +1,100 @@
+package org.apache.solr.handler.replication;
+
+import static org.apache.solr.handler.ClusterAPI.wrapParams;
+import static
org.apache.solr.security.PermissionNameProvider.Name.CORE_EDIT_PERM;
+
+import io.swagger.v3.oas.annotations.Operation;
+import io.swagger.v3.oas.annotations.media.Schema;
+import io.swagger.v3.oas.annotations.parameters.RequestBody;
+import java.util.HashMap;
+import java.util.Map;
+import javax.inject.Inject;
+import javax.ws.rs.POST;
+import javax.ws.rs.Path;
+import javax.ws.rs.PathParam;
+import javax.ws.rs.Produces;
+import javax.ws.rs.core.MediaType;
+import org.apache.solr.api.JerseyResource;
+import org.apache.solr.common.annotation.JsonProperty;
+import org.apache.solr.core.CoreContainer;
+import org.apache.solr.handler.ReplicationHandler;
+import org.apache.solr.jersey.JacksonReflectMapWriter;
+import org.apache.solr.jersey.PermissionName;
+import org.apache.solr.jersey.SolrJerseyResponse;
+import org.apache.solr.request.SolrQueryRequest;
+import org.apache.solr.response.SolrQueryResponse;
+
+/** V2 endpoint for Backup API used for User-Managed clusters and Single-Node
Installation. */
+@Path("/cores/{cores}/replication/backups")
+public class BackupAPI extends JerseyResource {
+ private final SolrQueryRequest solrQueryRequest;
+ private final SolrQueryResponse solrQueryResponse;
+ private final ReplicationHandler replicationHandler;
+
+ @PathParam("cores")
+ private String coreName;
+
+ @Inject
+ public BackupAPI(
+ CoreContainer cc, SolrQueryRequest solrQueryRequest, SolrQueryResponse
solrQueryResponse) {
+this.replicationHandler =
+(ReplicationHandler)
cc.getCore(coreName).getRequestHandler(ReplicationHandler.PATH);
Review Comment:
Yes the issue is that I was accessing `@PathParam` value in Constructor
and It was not available. That's why It was giving the Injection error. I
removed it. And, now it's able to create API's object. Thank you so much.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] iamsanjay commented on a diff in pull request #1119: [SOLR-16461] Create v2 equivalent of v1 ReplicationHandler 'BACKUP'
iamsanjay commented on code in PR #1119:
URL: https://github.com/apache/solr/pull/1119#discussion_r1004814541
##
solr/core/src/java/org/apache/solr/handler/admin/CoreAdminHandler.java:
##
@@ -452,6 +454,11 @@ void call() throws Exception {
}
}
+ @Override
Review Comment:
[Q] Does that mean the v2 API format will also change for '/replication'?
i.e. instead of starting with '/cores' Will it starts with '/replication'?
something like that.
```
/replication/{coreName}/backups
```
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] iamsanjay commented on a diff in pull request #1119: [SOLR-16461] Create v2 equivalent of v1 ReplicationHandler 'BACKUP'
iamsanjay commented on code in PR #1119:
URL: https://github.com/apache/solr/pull/1119#discussion_r1004814313
##
solr/core/src/java/org/apache/solr/handler/admin/CoreAdminHandler.java:
##
@@ -452,6 +454,11 @@ void call() throws Exception {
}
}
+ @Override
Review Comment:
Yes it's backup API from the `ReplicationHandler` but I assumed from the new
proposed v2 format that it goes into CoreAdminHandler as it starts with `/cores`
```
/cores/{coreName}/replication/backups
```
But yes you are right, this should goes inside ReplicationHandler. Also I
have not tried it yet, but going via CoreAdminHandler I will not have access to
the SolrParams that we configure in solrconfig.xml for ReplicationHandler.
```
optimize
optimize
schema.xml,stopwords.txt,elevate.xml
2
00:00:10
16
```
--
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.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] Jdurham2843 opened a new pull request, #1126: SOLR-16462: Create v2 equivalent of v1 'CREATESNAPSHOT', 'LISTSNAPSHOT' and 'DELETESNAPSHOT' (core level)
Jdurham2843 opened a new pull request, #1126: URL: https://github.com/apache/solr/pull/1126 https://issues.apache.org/jira/browse/SOLR-16462 # Description This pull request implements V2 equivalent endpoints for the Snapshot API (Create, List, and Delete). # Solution I created a SnapshotAPI class that houses new v2 implementations of the CreateSnapshot, ListSnapshot, and DeleteSnapshot operations. The SnapshotAPI endpoints were implemented using the Jersey JAX-RS reference implementation. The original CoreAdminOperation implementations were modified to call the new SnapshotAPI methods. The backup/restore reference documentation has been updated to show both V1 and V2 Snapshot API examples. # Tests No new tests were added, but I would be willing to add some if needed. There are existing tests that check that both the coreName and commitName were passed into a given Snapshot operation. Since those values are now part of the URL, I didn't see any reason to test for that against the new V2 methods. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://wiki.apache.org/solr/HowToContribute) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [x] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [x] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] HoustonPutman opened a new pull request, #1125: Fix useGpg signing without password
HoustonPutman opened a new pull request, #1125: URL: https://github.com/apache/solr/pull/1125 Also make the release wizard work. It is currently broken with respect to GPG signing. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16476) Remove commons-text dependency from solr-core
[
https://issues.apache.org/jira/browse/SOLR-16476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16476:
Resolution: Fixed
Status: Resolved (was: Patch Available)
another core dependency bites the dust :)
> Remove commons-text dependency from solr-core
> -
>
> Key: SOLR-16476
> URL: https://issues.apache.org/jira/browse/SOLR-16476
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, Build
>Reporter: David Smiley
>Assignee: Kevin Risden
>Priority: Minor
> Labels: newdev
> Fix For: main (10.0), 9.2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I don't think we +really+ need commons-text in solr-core. I see it's for
> only one usage:
> https://github.com/apache/solr/blob/c99af207c761ec34812ef1cc3054eb2804b7448b/solr/core/src/java/org/apache/solr/servlet/LoadAdminUiServlet.java#L83
> {noformat}
> String[] search = new String[] {"${contextPath}", "${adminPath}",
> "${version}"};
> String[] replace =
> new String[] {
> StringEscapeUtils.escapeEcmaScript(request.getContextPath()),
>
> StringEscapeUtils.escapeEcmaScript(CommonParams.CORES_HANDLER_PATH),
>
> StringEscapeUtils.escapeEcmaScript(pack.getSpecificationVersion())
> };
> {noformat}
> But contextPath & adminPath are no longer in our admin pages. "version" is.
> Regardless, I don't see why we need to escape EcmaScript; these variables
> come from internal/validated sources that will not have user provided data
> that could hack the pages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16476) Remove commons-text dependency from solr-core
[
https://issues.apache.org/jira/browse/SOLR-16476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16476:
Fix Version/s: 9.2
> Remove commons-text dependency from solr-core
> -
>
> Key: SOLR-16476
> URL: https://issues.apache.org/jira/browse/SOLR-16476
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, Build
>Reporter: David Smiley
>Assignee: Kevin Risden
>Priority: Minor
> Labels: newdev
> Fix For: main (10.0), 9.2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I don't think we +really+ need commons-text in solr-core. I see it's for
> only one usage:
> https://github.com/apache/solr/blob/c99af207c761ec34812ef1cc3054eb2804b7448b/solr/core/src/java/org/apache/solr/servlet/LoadAdminUiServlet.java#L83
> {noformat}
> String[] search = new String[] {"${contextPath}", "${adminPath}",
> "${version}"};
> String[] replace =
> new String[] {
> StringEscapeUtils.escapeEcmaScript(request.getContextPath()),
>
> StringEscapeUtils.escapeEcmaScript(CommonParams.CORES_HANDLER_PATH),
>
> StringEscapeUtils.escapeEcmaScript(pack.getSpecificationVersion())
> };
> {noformat}
> But contextPath & adminPath are no longer in our admin pages. "version" is.
> Regardless, I don't see why we need to escape EcmaScript; these variables
> come from internal/validated sources that will not have user provided data
> that could hack the pages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16476) Remove commons-text dependency from solr-core
[
https://issues.apache.org/jira/browse/SOLR-16476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623939#comment-17623939
]
ASF subversion and git services commented on SOLR-16476:
Commit b30a67ba31caf0fa1ae89517a9457f7740bbdbab in solr's branch
refs/heads/branch_9x from Kevin Risden
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=b30a67ba31c ]
SOLR-16476: Remove commons-text dependency from solr-core (#1122)
> Remove commons-text dependency from solr-core
> -
>
> Key: SOLR-16476
> URL: https://issues.apache.org/jira/browse/SOLR-16476
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, Build
>Reporter: David Smiley
>Assignee: Kevin Risden
>Priority: Minor
> Labels: newdev
> Fix For: main (10.0)
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I don't think we +really+ need commons-text in solr-core. I see it's for
> only one usage:
> https://github.com/apache/solr/blob/c99af207c761ec34812ef1cc3054eb2804b7448b/solr/core/src/java/org/apache/solr/servlet/LoadAdminUiServlet.java#L83
> {noformat}
> String[] search = new String[] {"${contextPath}", "${adminPath}",
> "${version}"};
> String[] replace =
> new String[] {
> StringEscapeUtils.escapeEcmaScript(request.getContextPath()),
>
> StringEscapeUtils.escapeEcmaScript(CommonParams.CORES_HANDLER_PATH),
>
> StringEscapeUtils.escapeEcmaScript(pack.getSpecificationVersion())
> };
> {noformat}
> But contextPath & adminPath are no longer in our admin pages. "version" is.
> Regardless, I don't see why we need to escape EcmaScript; these variables
> come from internal/validated sources that will not have user provided data
> that could hack the pages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on pull request #1121: SOLR-16363: DirectUpdateHandler2 should not throw UnknownFormatConversionException
risdenk commented on PR #1121: URL: https://github.com/apache/solr/pull/1121#issuecomment-1290889195 https://github.com/apache/solr/pull/1124 to remove String.format from DirectUpdateHandler2 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr-operator] mmoscher commented on issue #477: Support Zookeeper `probes` parameters in Apache Solr Operator helm charts.
mmoscher commented on issue #477: URL: https://github.com/apache/solr-operator/issues/477#issuecomment-1290888915 @iampranabroy yes, all resources (Solr + ZK) in the same namespace with NetworkPolicies denying all pod's egress traffic. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk opened a new pull request, #1124: SOLR-16363: DirectUpdateHandler2 remove String.format from error logging
risdenk opened a new pull request, #1124: URL: https://github.com/apache/solr/pull/1124 https://issues.apache.org/jira/browse/SOLR-16363 Follow on to https://github.com/apache/solr/pull/1121 that I merged too soon by mistake. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on pull request #1121: SOLR-16363: DirectUpdateHandler2 should not throw UnknownFormatConversionException
risdenk commented on PR #1121: URL: https://github.com/apache/solr/pull/1121#issuecomment-1290886169 > We wouldn't even need a test. I'm going to leave the test - it tests the `IllegalArgumentException` code path in `DirectUpdateHandler2` that doesn't seem to be tested elsewhere. new PR incoming soon w/ `String.format` removed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-16476) Remove commons-text dependency from solr-core
[
https://issues.apache.org/jira/browse/SOLR-16476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Risden updated SOLR-16476:
Fix Version/s: main (10.0)
> Remove commons-text dependency from solr-core
> -
>
> Key: SOLR-16476
> URL: https://issues.apache.org/jira/browse/SOLR-16476
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI, Build
>Reporter: David Smiley
>Assignee: Kevin Risden
>Priority: Minor
> Labels: newdev
> Fix For: main (10.0)
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I don't think we +really+ need commons-text in solr-core. I see it's for
> only one usage:
> https://github.com/apache/solr/blob/c99af207c761ec34812ef1cc3054eb2804b7448b/solr/core/src/java/org/apache/solr/servlet/LoadAdminUiServlet.java#L83
> {noformat}
> String[] search = new String[] {"${contextPath}", "${adminPath}",
> "${version}"};
> String[] replace =
> new String[] {
> StringEscapeUtils.escapeEcmaScript(request.getContextPath()),
>
> StringEscapeUtils.escapeEcmaScript(CommonParams.CORES_HANDLER_PATH),
>
> StringEscapeUtils.escapeEcmaScript(pack.getSpecificationVersion())
> };
> {noformat}
> But contextPath & adminPath are no longer in our admin pages. "version" is.
> Regardless, I don't see why we need to escape EcmaScript; these variables
> come from internal/validated sources that will not have user provided data
> that could hack the pages.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] DennisBerger1984 commented on pull request #1118: [SOLR-16489] CaffeineCache puts thread into infinite loop
DennisBerger1984 commented on PR #1118: URL: https://github.com/apache/solr/pull/1118#issuecomment-1290876283 Hi @ben-manes, I can confirm that. We've bumped the version in our gradle build and I just verified that in the resulting docker image the actual jar is 3.1.1. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] dsmiley commented on pull request #1121: SOLR-16363: DirectUpdateHandler2 should not throw UnknownFormatConversionException
dsmiley commented on PR #1121: URL: https://github.com/apache/solr/pull/1121#issuecomment-1290875227 Wow; let's allow more time to review please? -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16363) DirectUpdateHandler2 should not throw UnknownFormatConversionException
[
https://issues.apache.org/jira/browse/SOLR-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623934#comment-17623934
]
ASF subversion and git services commented on SOLR-16363:
Commit ff494dd12b14e0f5ea40c3011a2da146250f0f4f in solr's branch
refs/heads/main from Kevin Risden
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=ff494dd12b1 ]
SOLR-16363: DirectUpdateHandler2 should not throw
UnknownFormatConversionException (#1121)
> DirectUpdateHandler2 should not throw UnknownFormatConversionException
> --
>
> Key: SOLR-16363
> URL: https://issues.apache.org/jira/browse/SOLR-16363
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: UpdateRequestProcessors
>Affects Versions: 9.0, 8.11.2, 9.1
>Reporter: Aman Verma
>Assignee: Kevin Risden
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In certain situation, to handle IllegalArgumentException while adding doc to
> solr is linked below
> [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L249|https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.11.2/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L250]
> EDIT: Adding Code piece for current main branch:
> [https://github.com/apache/solr/blob/main/solr/core/src/java/org/apache/solr/update/DirectUpdateHandler2.java#L314]
>
> This can be problematic if IllegalArgumentException (of the following format)
> is thrown during processing of docs (in my case it was via Filters to
> URL-Decode a string)
>
> {code:java}
> java.lang.IllegalArgumentException: URLDecoder: Illegal hex characters in
> escape (%) pattern - Error at index 0 in: "sy"{code}
> The _iae.getMessage()_ in this case contains "{*}%){*}" which conflicts with
> String.format which would further throw
> {code:java}
> java.util.UnknownFormatConversionException: Conversion = ')'
> at java.util.Formatter.checkText(Unknown Source) ~[?:?]
> at java.util.Formatter.parse(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.util.Formatter.format(Unknown Source) ~[?:?]
> at java.lang.String.format(Unknown Source) ~[?:?]
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:249){code}
> This particular exception is not caught and as a result the BAD_REQUEST was
> never returned to the client along with failure point in the chain.
> The ticket is a proposal to make this more robust i.e., in this particular
> situation either getMessage() could replaceAll "%" or perhaps another try?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk commented on pull request #1121: SOLR-16363: DirectUpdateHandler2 should not throw UnknownFormatConversionException
risdenk commented on PR #1121: URL: https://github.com/apache/solr/pull/1121#issuecomment-1290875313 > Can we please consider not using String.format here at all? String.format is useful when there is non-trivial formatting. I don't think we should use String.format when a trivial String concatenation can do the job. I don't understand why some people reach for more complex tools like this when the language itself is adequate. hmm good point. I mistakenly hit the merge button on this trying to merge the commons-text one. I can follow up w/ this change. -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[GitHub] [solr] risdenk merged pull request #1121: SOLR-16363: DirectUpdateHandler2 should not throw UnknownFormatConversionException
risdenk merged PR #1121: URL: https://github.com/apache/solr/pull/1121 -- 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. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
