Re: [PR] SOLR-17447 : Support to early terminate a search based on maxHits per collector. [solr]
sijuv commented on PR #2960: URL: https://github.com/apache/solr/pull/2960#issuecomment-2704533403 In the current implementation, the _EarlyTerminatingCollector_ is not used in any code path. The collector is instantiated at only one place https://github.com/apache/solr/blob/ac3d349dac530cf1001d5113fc21b0fd641cc9d5/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L293 . Now this is done only if _getTerminateEarly()_ returns true. It will never return true since the setter is never invoked in any code path. I think @gus-asf mentioned that as well, It is an unused method. -- 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
[PR] Fix race condition when checking distrib async cmd status [solr]
HoustonPutman opened a new pull request, #3268: URL: https://github.com/apache/solr/pull/3268 This is a small fix and I really don't think it warrants a JIRA and especially a changelog entry. I can make a JIRA if people thinks it deserves one. The `DistributedApiAsyncTracker` mentioned that there could be a race condition between completing an asynchronous request and checking its status. This is causing very infrequent test failures, such as: `ReindexCollectionTest.testAbort`. The solution is to just check the ZK paths in reverse order from how they are updated. So when completing or canceling tasks, they are updated in the following order: 1. `trackedAsyncTasks.put(asyncId, ...)` or `trackedAsyncTasks.remove(asyncId)` 1. `inFlightAsyncTasks.deleteInFlightTask(asyncId)` Therefore in `getAsyncTaskRequestStatus(asyncId)`, we need to check `inFlightAsyncTasks` before `trackedAsyncTasks`. This means we can get a false-positive "Submitted" or "Running" result (race condition described below). But that will just lead to the client checking again at a later time, and the next time they call, `inFlightAsyncTasks` will have been updated and we will get the actual response from `trackedAsyncTasks`. Before this PR, the race condition would give us a false-negative "Operation failed. Please resubmit" result. (race condition described below). This would tell the client to try again, when in fact the task could have been successful. This false-negative is much worse than the false-positive described above. Race condition before this PR: (false-negative) 1. `getAsyncTaskRequestStatus()` -- `trackedAsyncTasks` is checked -- no response is found 1. `setTaskCompleted()` -- `trackedAsyncTasks` id is updated -- response is put into ZK 1. `setTaskCompleted()` -- `inFlightAsyncTasks` id is deleted -- asyncID is deleted from ZK 1. `getAsyncTaskRequestStatus()` -- `inFlightAsyncTasks ` is checked -- asyncId is not found * Return a failure - Assume node died because `inFlightAsyncTasks ` ephemeral node is gone Race condition after this PR: (false-positive) 1. `setTaskCompleted()` -- `trackedAsyncTasks` id is updated -- response is put into ZK 1. `getAsyncTaskRequestStatus()` -- `inFlightAsyncTasks ` is checked -- asyncId is found * Return that the task is in progress 1. `setTaskCompleted()` -- `inFlightAsyncTasks` id is deleted -- asyncID is deleted from ZK -- 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-17562) Unify v2 API streaming support
[
https://issues.apache.org/jira/browse/SOLR-17562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17934542#comment-17934542
]
Jason Gerlowski commented on SOLR-17562:
Yep, I'll close this out (but am happy to continue discussion, re: approach)
> I'm inclined to propose something different.
I'm not wedded to the InputStreamResponseParser approach, but I'm not sure I
really understand your proposal and how it differs. Having a new
"JacksonResponseParser" class that "gets placed onto a holder NamedList as
'response'" feels like it has a lot of overlap with how
InputStreamResponseParser works today.
Can you be a little more explicit on how it'd differ from today's
InputStreamResponseParser-based approach? Is Jackson parsing directly from an
InputStream into the structured type, or are we first parsing to some
intermediary format (Map or NamedList) and then having Jackson parse that into
a structured type?
Might be easier to discuss as a draft PR, if you're open to putting one
together?
> Unify v2 API streaming support
> --
>
> Key: SOLR-17562
> URL: https://issues.apache.org/jira/browse/SOLR-17562
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
>Reporter: Jason Gerlowski
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Several v2 APIs return raw files or streams of data, including:
> {{ZooKeeperReadAPI}}, {{NodeFileStore}}, and {{CoreReplication.fetchFile}}.
> But the APIs vary slightly in how they support this: ZooKeeperReadAPI uses
> the deprecated "ContentStream" with "RawResponseWriter", NodeFileStore
> directly attaches a "SolrCore.RawWriter" to the underlying SolrQueryResponse,
> and CoreReplication follows the JAX-RS best practice of using the
> "StreamingOutput" interface.
> This ticket aims to align all of these approaches and document our approach
> in {{dev-docs/apis.adoc}} or a similar file.
> The preferred approach ([see discussion
> here|https://github.com/apache/solr/pull/2734]) at the time of writing is to
> use StreamingOutput. If this doesn't change, this ticket will need to:
> * modify our Java codegen template and related code to support this new
> response type. (Java codegen currently requires that all responses subclass
> SolrJerseyResponse)
> * remove the "x-omitFromCodegen" tag from any APIs using StreamingOutput (see
> ReplicationApis.fetchFile for an example)
> * Switch other raw-file/streaming APIs over to using StreamingOutput.
> Validate v1 and v2 responses.
--
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
Re: [PR] Allow disabling new UI module during builds [solr]
HoustonPutman commented on PR #3261: URL: https://github.com/apache/solr/pull/3261#issuecomment-2718974649 Could we also disable it by default in the OS/Arch values we know are unsupported, as well as the ALT JDK option? -- 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
[PR] Update apache.curator to v5.8.0 [solr]
solrbot opened a new pull request, #3245: URL: https://github.com/apache/solr/pull/3245 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [org.apache.curator:curator-test](https://curator.apache.org) ([source](https://redirect.github.com/apache/curator)) | dependencies | minor | `5.7.1` -> `5.8.0` | | [org.apache.curator:curator-recipes](https://curator.apache.org) ([source](https://redirect.github.com/apache/curator)) | dependencies | minor | `5.7.1` -> `5.8.0` | | [org.apache.curator:curator-framework](https://curator.apache.org) ([source](https://redirect.github.com/apache/curator)) | dependencies | minor | `5.7.1` -> `5.8.0` | | [org.apache.curator:curator-client](https://curator.apache.org) ([source](https://redirect.github.com/apache/curator)) | dependencies | minor | `5.7.1` -> `5.8.0` | --- ### Configuration 📅 **Schedule**: Branch creation - "* * * * *" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://redirect.github.com/solrbot/renovate-github-action) -- 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
Re: [PR] SOLR-17438 Resolve committer GPG key from other source [solr]
janhoy commented on PR #3145: URL: https://github.com/apache/solr/pull/3145#issuecomment-2703529578 Any news on final location @madrob ? -- 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
Re: [PR] fix the solr zk invocation [solr-operator]
gerlowskija commented on PR #756: URL: https://github.com/apache/solr-operator/pull/756#issuecomment-2711077517 (Confirmed this PR works with Solr 8.11 as well - so we should be covered for the full range of supported Solr versions!) -- 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
Re: [PR] SOLR-17638 Some CLI errors not logged when starting prometheus exporter [solr]
epugh commented on code in PR #3236:
URL: https://github.com/apache/solr/pull/3236#discussion_r1994384497
##
solr/prometheus-exporter/src/java/org/apache/solr/prometheus/exporter/SolrExporter.java:
##
@@ -349,4 +361,31 @@ private static MetricsConfiguration
loadMetricsConfiguration(String configPath)
private static String getSystemVariable(String name) {
return System.getProperty(name, System.getenv(name));
}
+
+ // copied over from CLIUtils
+ public static void exit(int exitStatus) {
+try {
+ System.exit(exitStatus);
+} catch (java.lang.SecurityException secExc) {
+ if (exitStatus != 0)
+throw new RuntimeException("SolrExporter failed to exit with status "
+ exitStatus);
+}
+ }
+
+ // copied over from CLIUtils
+ private static String getDefaultSolrUrl() {
+// note that ENV_VAR syntax (and the env vars too) are mapped to env.var
sys props
+String scheme = EnvUtils.getProperty("solr.url.scheme", "http");
+String host = EnvUtils.getProperty("solr.tool.host", "localhost");
Review Comment:
agreed we should just use `solr.host`
--
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
Re: [PR] SOLR-17043: Remove SolrClient path pattern matching [solr]
jkmuriithi commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1996350108
##
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##
@@ -185,8 +188,31 @@ public void setQueryParams(Set queryParams) {
this.queryParams = queryParams;
}
- /** This method defines the type of this Solr request. */
- public abstract String getRequestType();
+ /**
+ * Defines the intended type of this Solr request.
+ *
+ * Subclasses should typically override this method instead of {@link
+ * SolrRequest#getRequestType}. Note that changing request type can
break/impact request routing
+ * within various clients (i.e. {@link CloudSolrClient}).
+ */
+ protected SolrRequestType getBaseRequestType() {
+return SolrRequestType.UNSPECIFIED;
+ }
+
+ /**
+ * Pattern matches on the underlying {@link SolrRequest} to identify ADMIN
requests and other
+ * special cases. If no special case is identified, {@link
SolrRequest#getBaseRequestType()} is
+ * returned.
+ */
+ public SolrRequestType getRequestType() {
+if (CommonParams.ADMIN_PATHS.contains(getPath())) {
+ return SolrRequestType.ADMIN;
+} else if (this instanceof IsUpdateRequest) {
Review Comment:
Removed this
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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
Re: [PR] SOLR-17688: Http2SolrClient: use Request.Listener not HttpListenerFactory [solr]
dsmiley commented on PR #3233: URL: https://github.com/apache/solr/pull/3233#issuecomment-2719102856 I've hit a blocking test failure in which https://issues.apache.org/jira/browse/SOLR-13510 has reappeared here because onQueued isn't necessarily called from the submitting thread :-( `org.apache.solr.security.BasicAuthOnSingleNodeTest#basicTest` It failed on me once; hasn't repeated. Even though I can guess I'll need to maybe call onQueued or similar, I want to deterministically induce the situation so it can better be understood and more consistently captured in a regression. -- 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-17704) Change ZkDistributedLock to use Curator
David Smiley created SOLR-17704: --- Summary: Change ZkDistributedLock to use Curator Key: SOLR-17704 URL: https://issues.apache.org/jira/browse/SOLR-17704 Project: Solr Issue Type: Sub-task Reporter: David Smiley Now that Solr is using Curator for connection management, we can finally use it to replace Solr code. ZkDistributedLock looks like very low-hanging fruit, used by the non-Overseer distributed mode. That mode is still experimental so we can change it in backwards-incompatible ways in Solr 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
Re: [PR] SOLR-17651: Make sure CLI unit tests don't call System.exit() [solr]
stillalex commented on code in PR #3258:
URL: https://github.com/apache/solr/pull/3258#discussion_r1995593321
##
solr/core/src/java/org/apache/solr/cli/ToolRuntime.java:
##
@@ -0,0 +1,39 @@
+/*
+ * 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.cli;
+
+/**
+ * An implementation of this class is specified when executing {@link
ToolBase} to access
+ * environment specific methods (mostly to differentiate test from non-test
executions for now).
+ *
+ * @see ToolBase
+ */
+public abstract class ToolRuntime {
Review Comment:
curious why you chose an abstract class over an interface here
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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
Re: [PR] fix the solr zk invocation [solr-operator]
gerlowskija commented on PR #756: URL: https://github.com/apache/solr-operator/pull/756#issuecomment-2710826399 Will do a sanity-check with 8.11 and start prepping to merge this. Thanks for the quick update @elangelo ! -- 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-14410) Switch from SysV init script to systemd service definition
[ https://issues.apache.org/jira/browse/SOLR-14410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated SOLR-14410: -- Labels: pull-request-available (was: ) > Switch from SysV init script to systemd service definition > -- > > Key: SOLR-14410 > URL: https://issues.apache.org/jira/browse/SOLR-14410 > Project: Solr > Issue Type: Improvement >Reporter: Marius Ghita >Assignee: Jan Høydahl >Priority: Major > Labels: pull-request-available > Fix For: main (10.0) > > Attachments: image-2023-05-24-03-02-50-824.png, > image-2023-05-24-03-14-14-991.png, solr.service > > Time Spent: 6h 40m > Remaining Estimate: 0h > > The proposed change will incorporate the attached service definition file in > the solr installation script. > > More information on the mailinglist > [http://mail-archives.apache.org/mod_mbox/lucene-dev/202004.mbox/%3ccafszzzxs+zh1mrscsjftyxn0kod_+6fjobxd9zhxt66fhaz...@mail.gmail.com%3e] -- 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
Re: [PR] SOLR-14410: switch from SysV to systemd service [solr]
davispuh commented on PR #428: URL: https://github.com/apache/solr/pull/428#issuecomment-2727008300 Wouldn't it be better to run `solr` in `foreground` mode? Then systemd would be able to log stderr/out in journal. Now that output is just dropped. I know that we don't lose logs because of separate log file but it might be simpler to allow journald to handle 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
Re: [PR] Solr 12276 angularjs to angular migration [solr]
NikolaiJDev closed pull request #2818: Solr 12276 angularjs to angular migration URL: https://github.com/apache/solr/pull/2818 -- 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
Re: [PR] Solr 12276 angularjs to angular migration [solr]
NikolaiJDev commented on PR #2818: URL: https://github.com/apache/solr/pull/2818#issuecomment-2726991544 Not needed anymore - CLOSED. -- 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
Re: [PR] SOLR-17043: Remove SolrClient path pattern matching [solr]
dsmiley commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1997236700
##
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##
@@ -130,9 +130,14 @@ public String getBasicAuthPassword() {
// -
// -
- public SolrRequest(METHOD m, String path) {
+ public SolrRequest(METHOD m, String path, SolrRequestType defaultType) {
this.method = m;
this.path = path;
+this.defaultType = defaultType;
+ }
+
+ public SolrRequest(METHOD m, String path) {
Review Comment:
The request type here would then be subtle/hidden at the caller site. I
think the caller of SolrRequest's constructor should be explicit about this.
##
solr/solrj/src/resources/java-template/api.mustache:
##
@@ -218,12 +219,6 @@ public class {{classname}} {
}
{{/bodyParam}}
-// TODO Hardcode this for now, but in reality we'll want to parse
this out of the Operation data somehow
Review Comment:
you removed this comment but isn't it still relevant?
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/CollectionRequiringSolrRequest.java:
##
@@ -22,6 +22,10 @@
/** Parent {@link SolrRequest} class that requires a target collection or
core. */
public abstract class CollectionRequiringSolrRequest
extends SolrRequest {
+ public CollectionRequiringSolrRequest(METHOD m, String path, SolrRequestType
defaultType) {
Review Comment:
why use the word "default" in "defaultType? why not just "requestType"?
--
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
Re: [PR] SOLR-17043: Remove SolrClient path pattern matching [solr]
dsmiley commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1997236700
##
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##
@@ -130,9 +130,14 @@ public String getBasicAuthPassword() {
// -
// -
- public SolrRequest(METHOD m, String path) {
+ public SolrRequest(METHOD m, String path, SolrRequestType defaultType) {
this.method = m;
this.path = path;
+this.defaultType = defaultType;
+ }
+
+ public SolrRequest(METHOD m, String path) {
Review Comment:
The request type here would then be subtle/hidden at the caller site. I
think the caller of SolrRequest's constructor should be explicit about this,
just as they are explicit about the method.
--
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
Re: [PR] SOLR-17043: Remove SolrClient path pattern matching [solr]
dsmiley commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r1997244468
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/SolrPing.java:
##
@@ -38,7 +38,8 @@ public class SolrPing extends
CollectionRequiringSolrRequest {
/** Create a new SolrPing object. */
public SolrPing() {
-super(METHOD.GET, CommonParams.PING_HANDLER);
+// this request is not processed as an admin request
+super(METHOD.GET, CommonParams.PING_HANDLER, SolrRequestType.UNSPECIFIED);
Review Comment:
ADMIN
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/schema/AbstractSchemaRequest.java:
##
@@ -38,9 +38,4 @@ public AbstractSchemaRequest(METHOD m, String path,
SolrParams params) {
public SolrParams getParams() {
return params;
}
-
- @Override
- public String getRequestType() {
-return SolrRequestType.ADMIN.toString();
Review Comment:
forgot to supply in constructor
##
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##
@@ -185,8 +193,21 @@ public void setQueryParams(Set queryParams) {
this.queryParams = queryParams;
}
- /** This method defines the type of this Solr request. */
- public abstract String getRequestType();
+ /**
+ * The type of this Solr request.
+ *
+ * Pattern matches {@link SolrRequest#getPath} to identify ADMIN requests
and other special
+ * cases. Overriding this method may affect request routing within various
clients (i.e. {@link
+ * CloudSolrClient}).
+ */
+ public SolrRequestType getRequestType() {
+String path = getPath();
+if (path != null && CommonParams.ADMIN_PATHS.contains(path)) {
Review Comment:
this part is troubling IMO; I think we should just return the field of the
requestType
##
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##
@@ -90,6 +92,7 @@ public enum SolrClientContext {
private METHOD method = METHOD.GET;
private String path = null;
+ private SolrRequestType defaultType = SolrRequestType.UNSPECIFIED;
Review Comment:
can we just call this field requestType? The word "default" isn't needed.
##
solr/core/src/java/org/apache/solr/handler/SolrConfigHandler.java:
##
@@ -1032,11 +1031,6 @@ public Boolean call() throws Exception {
protected SolrResponse createResponse(SolrClient client) {
return null;
}
-
-@Override
-public String getRequestType() {
Review Comment:
If you remove this here then you should supply ADMIN in the constructor.
This underscores a point I make in my review here that it should be explicit;
not an optional parameter.
##
solr/test-framework/src/java/org/apache/solr/cloud/ConfigRequest.java:
##
@@ -56,9 +56,4 @@ public RequestWriter.ContentWriter getContentWriter(String
expectedType) {
public SolrResponse createResponse(SolrClient client) {
return new SolrResponseBase();
}
-
- @Override
- public String getRequestType() {
-return SolrRequest.SolrRequestType.ADMIN.toString();
Review Comment:
forgot to then pass in constructor
##
solr/solrj/src/java/org/apache/solr/client/solrj/request/V2Request.java:
##
@@ -134,11 +134,6 @@ public ResponseParser getResponseParser() {
return super.getResponseParser();
}
- @Override
- public String getRequestType() {
-return SolrRequestType.ADMIN.toString();
Review Comment:
forgot to supply in constructor
##
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##
@@ -210,6 +236,16 @@ public boolean requiresCollection() {
return false;
}
+ /**
+ * Indicates if clients should make attempts to route this request to a
shard leader, overriding
+ * typical client routing preferences for requests. Defaults to true.
+ *
+ * @see CloudSolrClient#isUpdatesToLeaders
+ */
+ public boolean shouldSendToLeaders() {
Review Comment:
Indeed, the author has made this method more prominent by elevating to
SolrRequest, so my feedback is relevant & timely. I don't like this method
here at all (or anywhere).
> Are you suggesting we remove it altogether in favor of UpdateRequest
setting a shards.preference value, or something similar?
Exactly.
--
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
Re: [PR] Fix 'setup-zk' bash syntax error [solr-operator]
madrob commented on PR #769: URL: https://github.com/apache/solr-operator/pull/769#issuecomment-2725303749 I would consider pulling the entire scriptlets into separate files and then you can run spellcheck on those? -- 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
Re: [PR] SOLR-17651: Make sure CLI unit tests don't call System.exit() [solr]
HoustonPutman commented on PR #3258: URL: https://github.com/apache/solr/pull/3258#issuecomment-2725240315 This will also fix our failing Windows builds. Much easier to do this, than track down which test is failing there. -- 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
Re: [I] Solr -operator and prometheus-exporter [solr-operator]
HoustonPutman commented on issue #760: URL: https://github.com/apache/solr-operator/issues/760#issuecomment-2725179743 @aloosnetmatch can you provide the status of your solrcloud objects as well? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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-17702) ZkController should own its own reconnect logic
[
https://issues.apache.org/jira/browse/SOLR-17702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935553#comment-17935553
]
Houston Putman commented on SOLR-17702:
---
So what you mentioned at
[https://github.com/apache/curator/pull/514#discussion_r1887528639] and what
I'm mentioning here are very similar, but ultimately not related.
That PR relates to the watches executor, which I am very much not touching here
(This PR will not affect watches on nodes at all). This is the
connectionStateListenerExecutor, which does act as a watch, but from my
investigation in Curator, does not go through the same {{NamespaceWatcher}}
code-path that the node watcher logic goes through.
The shutdown logic ordering discussion is also very similar, and after thinking
about it a bit more, we probably don't need to be executing node watches after
shutdown either. But I would prefer that to live in another PR as well. Keep
things nice and tidy. (And could ultimately come with a full-scale re-doing of
how we think about async watch execution)
> ZkController should own its own reconnect logic
> ---
>
> Key: SOLR-17702
> URL: https://issues.apache.org/jira/browse/SOLR-17702
> Project: Solr
> Issue Type: Improvement
>Affects Versions: main (10.0)
>Reporter: Houston Putman
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since we use Curator now, the SolrZkClient is no longer in charge of
> maintaining onDisconnect and onReconnect listeners, Curator does. This means
> that SolrZkClient doesn't need to own their execution either.
> ZkController is the main usage of this logic, with big "onDisconnect" and
> "onReconnect" methods. However, when onReconnect is called just before a
> server is taken down, the ZkController does not own the executor for this
> reconnect logic, so we have to wait until the SolrZkClient is shut down (one
> of the last steps of shutting down a solr node).
> Instead, we can have the ZkController take control of the executor, so that
> we can ensure that reconnect and disconnect logic is stopped once "close()"
> is called.
> There are a few other places that use the SolrZkClient onReconnect()
> listener, but those can be transitioned to call Curator to add them.
> (ZkStateReader being the main one). And this is only going to go to main
> (10.0) since it requires Curator, so we don't need to worry about changing
> class/method signatures or back-compatibility.
> And one extra benefit is that we are slimming down one more thing from
> SolrZkClient (and maybe we can actually retire it one day)!
--
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
Re: [PR] Prevent RAW_GINKGO unset error in e2e tests [solr-operator]
gerlowskija merged PR #767: URL: https://github.com/apache/solr-operator/pull/767 -- 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
Re: [PR] Fix flaky TestSchemaDesignerAPI [solr]
HoustonPutman closed pull request #3213: Fix flaky TestSchemaDesignerAPI URL: https://github.com/apache/solr/pull/3213 -- 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
Re: [I] Solr 9.8.0 pods do not become ready [solr-operator]
gerlowskija commented on issue #761: URL: https://github.com/apache/solr-operator/issues/761#issuecomment-2711518166 Hi @aloosnetmatch - can you please share some more information to help us understand and reproduce the issue? 1. What does your SolrCloud resource configuration look like? Can you share the output of `kubectl get solrcloud -o yaml`? (Or alternately your helm values file, if that's easier?) 2. Can you see any relevant logs in the operator pod itself that show errors related to the 'solrCloud' in question? 3. Can you tell what's actually running on the pod? Are the Solr initContainers running, or does the pod proceed past those and start running the Solr container itself? If the latter, are there any errors in Solr's logs? -- 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
Re: [I] Solr -operator and prometheus-exporter [solr-operator]
gerlowskija commented on issue #760: URL: https://github.com/apache/solr-operator/issues/760#issuecomment-2718204202 I spent some time this morning trying to trigger this using the `release-0.9` branch (Operator 0.9.0, essentially), and Solr 9.8.0, and couldn't reproduce. Since @aloosnetmatch saw the behavior change after adding the missing "ZK_HOST" value, I tried telling the prometheus about its ZK_HOST a few different ways, including: ``` spec: solrReference: cloud: zkConnectionInfo: internalConnectionString: "example-solrcloud-zookeeper-0.example-solrcloud-zookeeper-headless.default.svc.cluster.local:2181" chroot: "/this/will/be/auto/created" ``` and ``` spec: solrReference: cloud: name: "example" ``` Neither one allowed me to reproduce, out of the box. @aloosnetmatch - could you share some more details about your solrcloud and solrprometheusexporter, that might help folks here reproduce? The output of commands like `kubectl get solrcloud -o yaml` and `kubectl get solrprometheusexporter -o yaml` would be a huge help. -- 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
Re: [PR] SOLR-17678 Add support to return original score ( the query score ) in case of r… [solr]
sijuv commented on code in PR #3222:
URL: https://github.com/apache/solr/pull/3222#discussion_r1984122197
##
solr/core/src/java/org/apache/solr/search/ReRankCollector.java:
##
@@ -205,18 +205,29 @@ public TopDocs topDocs(int start, int howMany) {
ScoreDoc[] scoreDocs = new ScoreDoc[howMany];
System.arraycopy(rescoredDocs.scoreDocs, 0, scoreDocs, 0, howMany);
rescoredDocs.scoreDocs = scoreDocs;
-return rescoredDocs;
}
+ return toRescoredDocs(rescoredDocs, docToOriginalScore);
Review Comment:
we dont have a handle to whether the `matchScore` field was requested at
this point. Only when we get to ReturnFields do we have this info. Hence we
need to have the logic of preserving the matchScore even if not requested.
--
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
Re: [PR] SOLR-10998: Obey 'Accept' header in v2 APIs [solr]
dsmiley commented on PR #3262: URL: https://github.com/apache/solr/pull/3262#issuecomment-2726984646 I love what you wrote -- what this PR accomplishes. It's a mystery to me **how** this PR accomplishes that goal. A test would be nice. -- 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
Re: [PR] SOLR-17651: Make sure CLI unit tests don't call System.exit() [solr]
epugh commented on code in PR #3258:
URL: https://github.com/apache/solr/pull/3258#discussion_r1991163882
##
solr/core/src/test/org/apache/solr/cli/CLITestHelper.java:
##
@@ -0,0 +1,113 @@
+/*
+ * 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.cli;
+
+import static org.apache.solr.cli.SolrCLI.findTool;
+import static org.apache.solr.cli.SolrCLI.parseCmdLine;
+import static org.junit.Assert.assertEquals;
+
+import java.io.PrintWriter;
+import java.io.Reader;
+import java.io.StringReader;
+import java.io.StringWriter;
+import org.apache.commons.cli.CommandLine;
+
+public class CLITestHelper {
+
+ /**
+ * Run a tool with all parameters, as specified in the command line. Fist
parameter must be the
Review Comment:
```suggestion
* Run a tool with all parameters, as specified in the command line. First
parameter must be the
```
##
solr/core/src/test/org/apache/solr/cli/CLITestHelper.java:
##
@@ -0,0 +1,113 @@
+/*
+ * 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.cli;
+
+import static org.apache.solr.cli.SolrCLI.findTool;
+import static org.apache.solr.cli.SolrCLI.parseCmdLine;
+import static org.junit.Assert.assertEquals;
+
+import java.io.PrintWriter;
+import java.io.Reader;
+import java.io.StringReader;
+import java.io.StringWriter;
+import org.apache.commons.cli.CommandLine;
+
+public class CLITestHelper {
+
+ /**
+ * Run a tool with all parameters, as specified in the command line. Fist
parameter must be the
+ * tool name.
+ *
+ * @param args Complete command line.
+ * @param clazz Expected class name of tool implementation.
+ */
+ public static int runTool(String[] args, Class clazz) throws Exception {
+ToolRuntime runtime = new ValidatingRuntime();
+return runTool(args, runtime, clazz);
+ }
+
+ /**
+ * Run a tool with all parameters, as specified in the command line. Fist
parameter must be the
+ * tool name.
+ *
+ * @param args Complete command line.
+ * @param runtime The runtime implementation specified to the tool. In test,
should be usually a
+ * test specific implementation for additional checks.
Review Comment:
would it make sense to have a @link for the next person to the specific
class?
##
solr/core/src/test/org/apache/solr/cli/PackageToolTest.java:
##
@@ -94,7 +94,8 @@ private > T
withBasicAuth(T req) {
@Test
public void testPackageTool() throws Exception {
-PackageTool tool = new PackageTool();
+ToolRuntime runtime = new CLITestHelper.ValidatingRuntime();
Review Comment:
why not also the `BufferingRuntime` and use that to check the outputs?
##
solr/core/src/test/org/apache/solr/cli/TestSolrCLIRunExample.java:
##
@@ -370,13 +362,12 @@ protected void testExample(String exampleName) throws
Exception {
};
// capture tool output to stdout
- ByteArrayOutputStream baos = new ByteArrayOutputStream();
Review Comment:
Not having these `baos` is nice...
##
solr/core/src/test/org/apache/solr/cli/StatusToolTest.java:
##
@@ -0,0 +1,51 @@
+/*
+ * 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 ma
[jira] [Comment Edited] (SOLR-17691) Request for Patch for Solr 8.4 - Zookeeper Status Error ("For input string: 'null'")
[
https://issues.apache.org/jira/browse/SOLR-17691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17933186#comment-17933186
]
Aviral Sinha edited comment on SOLR-17691 at 3/7/25 3:18 AM:
-
Hi Jan,
Thanks for your response.
I checked out the Solr 8.4 solution from the release tag *8.4* and compiled the
code, but I encountered an error. Please find the attached error details.
Could you advise if there's a workaround for this issue, so that i can apply
the fix from the mentioned issues to the *branch_8_4* source and building a
custom release
Looking forward to your guidance.
Best regards,
was (Author: JIRAUSER308915):
Hi Jan,
Thanks for your response.
I checked out the Solr 8.4 solution from the release tag *8.4* and compiled the
code, but I encountered an error. Please find the attached error details.
Could you advise if there's a workaround for this issue, or would applying the
fix from the mentioned issues to the *branch_8_4* source and building a custom
release be the only viable option?
Looking forward to your guidance.
Best regards,
> Request for Patch for Solr 8.4 - Zookeeper Status Error ("For input string:
> 'null'")
> -
>
> Key: SOLR-17691
> URL: https://issues.apache.org/jira/browse/SOLR-17691
> Project: Solr
> Issue Type: Bug
>Affects Versions: 8.4
> Environment: UAT/PROD
>Reporter: Aviral Sinha
>Priority: Critical
> Labels: patch
> Attachments: Solr8.4SourceCompilationError.txt, solrError.jpeg
>
>
> We are currently using {*}Sitecore 10 CMS{*}, which only supports {*}Solr
> 8.4{*}. Previously, we were using {*}ZooKeeper 3.4.14{*}, but since it has
> reached End of Life (EOL), we have upgraded to {*}ZooKeeper 3.8.4{*}.
> After upgrading and configuring Solr to point to the ZooKeeper host
> ({{{}zk_host{}}}), we are encountering an error on the {*}Solr Admin Page →
> ZooKeeper Status{*}:
> *"For input string: 'null'"*
> Please find the attached screenshot for reference.
> We noticed that this issue has already been addressed in later Solr versions,
> as referenced in the following JIRA cases:
> * SOLR-14463
> * SOLR-14669
> Since {*}our Sitecore application depends on Solr 8.4{*}, we are unable to
> upgrade to a higher Solr version. We kindly request you to provide a patch
> for Solr 8.4 to resolve this issue.
> Looking forward to your response.
--
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
Re: [PR] Demonstrate roundtrip export/import works [solr]
github-actions[bot] commented on PR #2940: URL: https://github.com/apache/solr/pull/2940#issuecomment-2727066623 This PR has had no activity for 60 days and is now labeled as stale. Any new activity will remove the stale label. To attract more reviewers, please tag people who might be familiar with the code area and/or notify the d...@solr.apache.org mailing list. To exempt this PR from being marked as stale, make it a draft PR or add the label "exempt-stale". If left unattended, this PR will be closed after another 60 days of inactivity. Thank you for your contribution! -- 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
Re: [PR] Fix 'setup-zk' bash syntax error [solr-operator]
gerlowskija commented on PR #769:
URL: https://github.com/apache/solr-operator/pull/769#issuecomment-2725240241
I think our existing testing (see
`tests/e2e/solrcloud_security_json_test.go`) is sufficient here. It never
caught the #759 error, because it's not actually an error ("just" some noise in
the logs)!
`grep -q` does print a message to stderr, but it doesn't impact the return
status of the `grep` call, which returns zero/non-zero based on whether it
finds a match in `/tmp/current_security.json`. `grep` doesn't care that you
also asked it to search other files (i.e. `]`) that don't exist. So despite
the syntax error, the overall conditional still operated as we wanted it to.
We could add an additional test case to `solrcloud_security_json_test.go`,
to cover the case of a security.json file whose contents are `{}`, but IMO that
edgecase is rare enough that it's not worth bloating the runtime of our e2e
tests.
If anyone disagrees though, lmk and I'll add it in. Otherwise, I'll
probably target early next week to merge this.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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-17699) High Query Time in Solr When Using OR with frange in fq
[
https://issues.apache.org/jira/browse/SOLR-17699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17935796#comment-17935796
]
David Smiley commented on SOLR-17699:
-
I pushed a test.
My first attempt to test it used a different test query that was simpler,
revealing a performance problem in Lucene, which I reported
[https://github.com/apache/lucene/pull/14357]
> High Query Time in Solr When Using OR with frange in fq
> ---
>
> Key: SOLR-17699
> URL: https://issues.apache.org/jira/browse/SOLR-17699
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Affects Versions: 9.0, 9.6.1
>Reporter: Puneet Sharma
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> h3. High Query Time in Solr When Using {{OR}} with {{frange}} in {{fq}}
> I am experiencing high query times in Solr when using an {{fq}} filter that
> combines an {{OR}} condition with {{{}frange{}}}. The response time
> significantly increases compared to queries that do not use this combination.
> h4. Query Example
>
> {{fq=\{!cache=false tag=prm}field:value OR \{!frange l=1 u=1 v=$funcQuery}}}
> Here, {{$funcQuery}} is a function query that retrieves documents dynamically
> based on dynamic parameters.
> h4. Observations
> * When I use just {{{}{!frange l=1 u=1 v=$funcQuery}{}}}, the query executes
> quickly[20ms].
> * When I use {{{!cache=false tag=prm}field:value}} alone, the query is also
> fast.
> * However, when combining both with {{{}OR{}}}, the query time increases
> significantly [700ms].
> * The dataset is relatively large, but other queries with similar complexity
> run efficiently.
> h4. Questions
> # Why does the {{OR}} operation with {{frange}} cause a significant increase
> in query time?
> # Are there any optimizations or alternative query structures that could
> improve performance?
> # Would it help to restructure how function queries and filters are applied
> in this case?
> # Is there any alternative for frange for this use case because in our use
> case, this cannot be done at index time because the function parameters
> change very frequently?
> Any insights or suggestions would be greatly appreciated!
--
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
