Re: [PR] SOLR-17275: Major performance regression of CloudSolrClient in Solr 9.6.0 when using aliases [solr]
dsmiley commented on PR #2463: URL: https://github.com/apache/solr/pull/2463#issuecomment-2113480275 Can you please update CHANGES.txt under 9.6.1 bug fix, maybe say: > SOLR-17275: SolrJ ZkClientClusterStateProvider, revert SOLR-17153 for regression when aliases are used. (your name) -- 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-17275) Major performance regression of CloudSolrClient in Solr 9.6.0 when using aliases
[
https://issues.apache.org/jira/browse/SOLR-17275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846758#comment-17846758
]
David Smiley commented on SOLR-17275:
-
I'll merge the change tomorrow morning to ensure anyone else has an opportunity
to review.
It's surprising to see that forceUpdateCollection has this global
synchronization lock, and that it was *this*, not some extra ZK call, that is
the root of the problem.
> Major performance regression of CloudSolrClient in Solr 9.6.0 when using
> aliases
>
>
> Key: SOLR-17275
> URL: https://issues.apache.org/jira/browse/SOLR-17275
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.6.0
> Environment: SolrJ 9.6.0, Ubuntu 22.04, Java 17
>Reporter: Rafał Harabień
>Priority: Blocker
> Fix For: 9.6.1
>
> Attachments: image-2024-05-06-17-23-42-236.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I observe worse performance of CloudSolrClient after upgrading from SolrJ
> 9.5.0 to 9.6.0, especially on p99.
> p99 jumped from ~25 ms to ~400 ms
> p90 jumped from ~9.9 ms to ~22 ms
> p75 jumped from ~7 ms to ~11 ms
> p50 jumped from ~4.5 ms to ~7.5 ms
> Screenshot from Grafana (at ~14:30 was deployed the new version):
> !image-2024-05-06-17-23-42-236.png!
> I've got a thread-dump and I can see many threads waiting in
> [ZkStateReader.forceUpdateCollection|https://github.com/apache/solr/blob/f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L503]:
> {noformat}
> Thread info: "suggest-solrThreadPool-thread-52" prio=5 Id=600 BLOCKED on
> org.apache.solr.common.cloud.ZkStateReader@62e6bc3d owned by
> "suggest-solrThreadPool-thread-34" Id=582
> at
> app//org.apache.solr.common.cloud.ZkStateReader.forceUpdateCollection(ZkStateReader.java:506)
> - blocked on org.apache.solr.common.cloud.ZkStateReader@62e6bc3d
> at
> app//org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.getState(ZkClientClusterStateProvider.java:155)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.resolveAliases(CloudSolrClient.java:1207)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1099)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:892)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:820)
> at
> app//org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:255)
> at
> app//org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:927)
> ...
> Number of locked synchronizers = 1
> - java.util.concurrent.ThreadPoolExecutor$Worker@1beb7ed3
> {noformat}
> At the same time qTime from Solr hasn't changed so I'm pretty sure it's a
> client regression.
> I've tried reproducing it locally and I can see
> [forceUpdateCollection|https://github.com/apache/solr/blob/f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L503]
> function being called for every request in my application. I can see that
> [this|https://github.com/apache/solr/commit/8cf552aa3642be473c6a08ce44feceb9cbe396d7]
> commit
> changed the logic in ZkClientClusterStateProvider.getState so the mentioned
> function gets called if clusterState.getCollectionRef [returns
> null|https://github.com/apache/solr/blob/f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr/solrj-zookeeper/src/java/org/apache/solr/client/solrj/impl/ZkClientClusterStateProvider.java#L151].
> In 9.5.0 it wasn't the case (forceUpdateCollection was not called in this
> place). I can see in the debugger that getCollectionRef only supports
> collections and not aliases (collectionStates map contains only collections).
> In my application all collections are referenced using aliases so I guess
> that's why I can see the regression in Solr response time.
> I am not familiar with the code enough to prepare a PR but I hope this
> insight will be enough to fix this issue.
--
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-10654: Introduce output of Prometheus metrics for Solr Core registry [solr]
mlbiscoc commented on PR #2405: URL: https://github.com/apache/solr/pull/2405#issuecomment-2113445818 @dsmiley or anyone else interested in reviewing. Was curious for more feedback on approach. Is this going in the correct direction or do some disagree if this is correct implementation path towards prometheus in Solr. -- 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-17275) Major performance regression of CloudSolrClient in Solr 9.6.0 when using aliases
[
https://issues.apache.org/jira/browse/SOLR-17275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846729#comment-17846729
]
Aparna Suresh edited comment on SOLR-17275 at 5/15/24 6:53 PM:
---
I have reverted the change on the client side to call forceUpdateCollection()
every time an alias is resolved. I think the performance impact was in terms of
introducing contention in forceUpdateCollection() (but not invoking ZK
getData() in any way), since it synchronizes on ZkStateReader object, but
should otherwise return pretty quickly, since calls to both
{code:java}
clusterState.getCollectionRef(collection){code}
and
{code:java}
tryLazyCollection.get(){code}
should return null for an alias.
Nevertheless the revert makes sense since the call to
{code:java}
CloudSolrClient.resolveAlias(){code}
should not ultimately call
{code:java}
ZkStateReader.forceUpdateCollection(){code}
since the latter is relevant only for collections.
was (Author: JIRAUSER302780):
I have reverted the change on the client side to call forceUpdateCollection()
every time an alias is resolved. I think the performance impact was in terms of
introducing contention in forceUpdateCollection(), since it synchronizes on
ZkStateReader object, but should otherwise return pretty quickly, since calls
to both
{code:java}
clusterState.getCollectionRef(collection){code}
and
{code:java}
tryLazyCollection.get(){code}
should return null for an alias.
Nevertheless the revert makes sense since the call to
{code:java}
CloudSolrClient.resolveAlias(){code}
should not ultimately call
{code:java}
ZkStateReader.forceUpdateCollection(){code}
since the latter is relevant only for collections.
> Major performance regression of CloudSolrClient in Solr 9.6.0 when using
> aliases
>
>
> Key: SOLR-17275
> URL: https://issues.apache.org/jira/browse/SOLR-17275
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.6.0
> Environment: SolrJ 9.6.0, Ubuntu 22.04, Java 17
>Reporter: Rafał Harabień
>Priority: Blocker
> Fix For: 9.6.1
>
> Attachments: image-2024-05-06-17-23-42-236.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I observe worse performance of CloudSolrClient after upgrading from SolrJ
> 9.5.0 to 9.6.0, especially on p99.
> p99 jumped from ~25 ms to ~400 ms
> p90 jumped from ~9.9 ms to ~22 ms
> p75 jumped from ~7 ms to ~11 ms
> p50 jumped from ~4.5 ms to ~7.5 ms
> Screenshot from Grafana (at ~14:30 was deployed the new version):
> !image-2024-05-06-17-23-42-236.png!
> I've got a thread-dump and I can see many threads waiting in
> [ZkStateReader.forceUpdateCollection|https://github.com/apache/solr/blob/f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L503]:
> {noformat}
> Thread info: "suggest-solrThreadPool-thread-52" prio=5 Id=600 BLOCKED on
> org.apache.solr.common.cloud.ZkStateReader@62e6bc3d owned by
> "suggest-solrThreadPool-thread-34" Id=582
> at
> app//org.apache.solr.common.cloud.ZkStateReader.forceUpdateCollection(ZkStateReader.java:506)
> - blocked on org.apache.solr.common.cloud.ZkStateReader@62e6bc3d
> at
> app//org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.getState(ZkClientClusterStateProvider.java:155)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.resolveAliases(CloudSolrClient.java:1207)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1099)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:892)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:820)
> at
> app//org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:255)
> at
> app//org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:927)
> ...
> Number of locked synchronizers = 1
> - java.util.concurrent.ThreadPoolExecutor$Worker@1beb7ed3
> {noformat}
> At the same time qTime from Solr hasn't changed so I'm pretty sure it's a
> client regression.
> I've tried reproducing it locally and I can see
> [forceUpdateCollection|https://github.com/apache/solr/blob/f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L503]
> function being called for every request in my application. I can see that
> [this|https://github.com/apache/solr/commit/8cf552aa3642be473c6a08ce44feceb9cbe396d7]
> commit
> changed the logic in ZkClientClusterStateProvider.getState so the
Re: [PR] SOLR-17275: Major performance regression of CloudSolrClient in Solr 9.6.0 when using aliases [solr]
dsmiley commented on PR #2463: URL: https://github.com/apache/solr/pull/2463#issuecomment-2113240161 +1 for reverting this piece. I think we'll come back to it later when we have more time to reconsider it. I strongly suspected the root cause was an extra ZK interaction but your testing & code sleuthing suggested it's actually the `synchronized` -- interesting. This is a problem Solr-side too, I suppose. -- 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-4587: integrate lucene-monitor into solr [solr]
kotman12 commented on code in PR #2382:
URL: https://github.com/apache/solr/pull/2382#discussion_r1602087557
##
solr/modules/monitor/src/java/org/apache/solr/monitor/update/MonitorUpdateRequestProcessor.java:
##
@@ -0,0 +1,257 @@
+/*
+ *
+ * * 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.monitor.update;
+
+import java.io.IOException;
+import java.io.Reader;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.Optional;
+import java.util.stream.Collectors;
+import java.util.stream.Stream;
+import org.apache.lucene.analysis.Analyzer;
+import org.apache.lucene.analysis.TokenStream;
+import org.apache.lucene.document.Document;
+import org.apache.lucene.document.Field;
+import org.apache.lucene.document.InvertableType;
+import org.apache.lucene.document.StoredValue;
+import org.apache.lucene.index.DocValuesType;
+import org.apache.lucene.index.IndexableField;
+import org.apache.lucene.index.IndexableFieldType;
+import org.apache.lucene.monitor.MonitorFields;
+import org.apache.lucene.monitor.MonitorQuery;
+import org.apache.lucene.monitor.Presearcher;
+import org.apache.lucene.monitor.QCEVisitor;
+import org.apache.lucene.util.BytesRef;
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.SolrInputDocument;
+import org.apache.solr.common.util.JavaBinCodec;
+import org.apache.solr.core.SolrCore;
+import org.apache.solr.monitor.MonitorConstants;
+import org.apache.solr.monitor.MonitorSchemaFields;
+import org.apache.solr.monitor.SimpleQueryParser;
+import org.apache.solr.schema.IndexSchema;
+import org.apache.solr.schema.SchemaField;
+import org.apache.solr.update.AddUpdateCommand;
+import org.apache.solr.update.processor.UpdateRequestProcessor;
+
+public class MonitorUpdateRequestProcessor extends UpdateRequestProcessor {
+
+ private final SolrCore core;
+ private final IndexSchema indexSchema;
+ private final Presearcher presearcher;
+ private final MonitorSchemaFields monitorSchemaFields;
+
+ public MonitorUpdateRequestProcessor(
+ UpdateRequestProcessor next, SolrCore core, Presearcher presearcher) {
+super(next);
+this.core = core;
+this.indexSchema = core.getLatestSchema();
+this.presearcher = presearcher;
+this.monitorSchemaFields = new MonitorSchemaFields(indexSchema);
+ }
+
+ @Override
+ public void processAdd(AddUpdateCommand cmd) throws IOException {
+var solrInputDocument = cmd.getSolrInputDocument();
+var queryId =
+(String)
solrInputDocument.getFieldValue(indexSchema.getUniqueKeyField().getName());
+var queryFieldValue =
solrInputDocument.getFieldValue(MonitorFields.MONITOR_QUERY);
+if (queryFieldValue != null) {
+ var payload =
+
Optional.ofNullable(solrInputDocument.getFieldValue(MonitorFields.PAYLOAD))
+ .map(Object::toString)
+ .orElse(null);
+ List children =
+ Optional.of(queryFieldValue)
+ .filter(String.class::isInstance)
+ .map(String.class::cast)
+ .map(
+ queryStr ->
+ new MonitorQuery(
+ queryId, SimpleQueryParser.parse(queryStr, core),
queryStr, Map.of()))
+ .stream()
+ .flatMap(monitorQuery -> decompose(monitorQuery, payload))
+ .map(this::toSolrInputDoc)
+ .collect(Collectors.toList());
+ if (children.isEmpty()) {
+throw new SolrException(
+SolrException.ErrorCode.INVALID_STATE, "Query could not be
decomposed");
+ }
+ SolrInputDocument firstChild = children.get(0);
+ if (solrInputDocument.hasChildDocuments()) {
+solrInputDocument.getChildDocuments().clear();
+ }
+
solrInputDocument.addChildDocuments(children.stream().skip(1).collect(Collectors.toList()));
+ if (solrInputDocument.hasChildDocuments()) {
+solrInputDocument
+.getChildDocuments()
+.forEach(
+child ->
+solrInputDocument.forEach(
+field -> {
+ if
[jira] [Commented] (SOLR-17275) Major performance regression of CloudSolrClient in Solr 9.6.0 when using aliases
[
https://issues.apache.org/jira/browse/SOLR-17275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846729#comment-17846729
]
Aparna Suresh commented on SOLR-17275:
--
I have reverted the change on the client side to call forceUpdateCollection()
every time an alias is resolved. I think the performance impact was in terms of
introducing contention in forceUpdateCollection(), since it synchronizes on
ZkStateReader object, but should otherwise return pretty quickly, since calls
to both
{code:java}
clusterState.getCollectionRef(collection){code}
and
{code:java}
tryLazyCollection.get(){code}
should return null for an alias.
Nevertheless the revert makes sense since the call to
{code:java}
CloudSolrClient.resolveAlias(){code}
should not ultimately call
{code:java}
ZkStateReader.forceUpdateCollection(){code}
since the latter is relevant only for collections.
> Major performance regression of CloudSolrClient in Solr 9.6.0 when using
> aliases
>
>
> Key: SOLR-17275
> URL: https://issues.apache.org/jira/browse/SOLR-17275
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.6.0
> Environment: SolrJ 9.6.0, Ubuntu 22.04, Java 17
>Reporter: Rafał Harabień
>Priority: Blocker
> Fix For: 9.6.1
>
> Attachments: image-2024-05-06-17-23-42-236.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I observe worse performance of CloudSolrClient after upgrading from SolrJ
> 9.5.0 to 9.6.0, especially on p99.
> p99 jumped from ~25 ms to ~400 ms
> p90 jumped from ~9.9 ms to ~22 ms
> p75 jumped from ~7 ms to ~11 ms
> p50 jumped from ~4.5 ms to ~7.5 ms
> Screenshot from Grafana (at ~14:30 was deployed the new version):
> !image-2024-05-06-17-23-42-236.png!
> I've got a thread-dump and I can see many threads waiting in
> [ZkStateReader.forceUpdateCollection|https://github.com/apache/solr/blob/f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L503]:
> {noformat}
> Thread info: "suggest-solrThreadPool-thread-52" prio=5 Id=600 BLOCKED on
> org.apache.solr.common.cloud.ZkStateReader@62e6bc3d owned by
> "suggest-solrThreadPool-thread-34" Id=582
> at
> app//org.apache.solr.common.cloud.ZkStateReader.forceUpdateCollection(ZkStateReader.java:506)
> - blocked on org.apache.solr.common.cloud.ZkStateReader@62e6bc3d
> at
> app//org.apache.solr.client.solrj.impl.ZkClientClusterStateProvider.getState(ZkClientClusterStateProvider.java:155)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.resolveAliases(CloudSolrClient.java:1207)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.sendRequest(CloudSolrClient.java:1099)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.requestWithRetryOnStaleState(CloudSolrClient.java:892)
> at
> app//org.apache.solr.client.solrj.impl.CloudSolrClient.request(CloudSolrClient.java:820)
> at
> app//org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:255)
> at
> app//org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:927)
> ...
> Number of locked synchronizers = 1
> - java.util.concurrent.ThreadPoolExecutor$Worker@1beb7ed3
> {noformat}
> At the same time qTime from Solr hasn't changed so I'm pretty sure it's a
> client regression.
> I've tried reproducing it locally and I can see
> [forceUpdateCollection|https://github.com/apache/solr/blob/f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L503]
> function being called for every request in my application. I can see that
> [this|https://github.com/apache/solr/commit/8cf552aa3642be473c6a08ce44feceb9cbe396d7]
> commit
> changed the logic in ZkClientClusterStateProvider.getState so the mentioned
> function gets called if clusterState.getCollectionRef [returns
> null|https://github.com/apache/solr/blob/f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr/solrj-zookeeper/src/java/org/apache/solr/client/solrj/impl/ZkClientClusterStateProvider.java#L151].
> In 9.5.0 it wasn't the case (forceUpdateCollection was not called in this
> place). I can see in the debugger that getCollectionRef only supports
> collections and not aliases (collectionStates map contains only collections).
> In my application all collections are referenced using aliases so I guess
> that's why I can see the regression in Solr response time.
> I am not familiar with the code enough to prepare a PR but I hope this
> insight will be enough to fix this issue.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] SOLR-4587: integrate lucene-monitor into solr [solr]
kotman12 commented on code in PR #2382:
URL: https://github.com/apache/solr/pull/2382#discussion_r1602065616
##
solr/modules/monitor/src/java/org/apache/lucene/monitor/MonitorFields.java:
##
@@ -0,0 +1,38 @@
+/*
+ *
+ * * Licensed to the Apache Software Foundation (ASF) under one or more
+ * * contributor license agreements. See the NOTICE file distributed with
+ * * this work for additional information regarding copyright ownership.
+ * * The ASF licenses this file to You under the Apache License, Version 2.0
+ * * (the "License"); you may not use this file except in compliance with
+ * * the License. You may obtain a copy of the License at
+ * *
+ * * http://www.apache.org/licenses/LICENSE-2.0
+ * *
+ * * Unless required by applicable law or agreed to in writing, software
+ * * distributed under the License is distributed on an "AS IS" BASIS,
+ * * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * * See the License for the specific language governing permissions and
+ * * limitations under the License.
+ *
+ */
+
+package org.apache.lucene.monitor;
+
+import java.util.Set;
+
+public class MonitorFields {
+
+ public static final String QUERY_ID = QueryIndex.FIELDS.query_id + "_";
+ public static final String CACHE_ID = QueryIndex.FIELDS.cache_id + "_";
+ public static final String MONITOR_QUERY = QueryIndex.FIELDS.mq + "_";
+ public static final String PAYLOAD = QueryIndex.FIELDS.mq + "_payload_";
Review Comment:
So echoing one of your earlier points about limiting the scope of the
initial phase, payload is one of those things that would be on my cutting
block. Initially I tried to have something that would effectively equate to the
[optional lucene-monitor metadata
map](https://github.com/apache/lucene/blob/main/lucene/monitor/src/java/org/apache/lucene/monitor/MonitorQuery.java#L43).
I believe the point of this is to return back that metadata in case there is
something useful that you want to associate with an indexed query.
Functionally, it serves the same purpose to a stored/doc-values solr field but
in a much less flexible and less normalized way. What's funny is that I haven't
actually wired this into the response yet because I don't think any of the
default lucene-monitor responses pass it back and I was simply going for
feature parity. That aside, is there a particular reason you were exploring
making the payload field name overridable? Maybe to let users give it a more
self-descri
bing name for their particular use case?
The difference between a query decomposer and a decoder is that the
decomposer takes an in-memory `Query` object and splits it into `List`
where each element is a presumably smaller disjunct that is less expensive to
match in the final phase (think for example of an or-expression with 500 terms
.. each one of those can be indexed/matched separately for a much faster
matching phase). A query decoder simply takes the original full query string
and parses it to the original full/undecomposed `Query` (and yes .. it wraps it
in a `MonitorQuery` and that is where the `id` and that annoying `payload`
business comes into play). After that you have to split it into the disjuncts
again as [there is no _easy_ and _general_
way](https://stackoverflow.com/a/16966866) to serialize those inner `Query`s.
That detail aside, I don't see any reason the decoder can't use the decomposer
directly and expose that decomposition as part of its API ... this is more of
me explaining this distinction
between lucene's original `MonitorQuerySerializer` and `QueryDecomposer`.
--
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-4587: integrate lucene-monitor into solr [solr]
kotman12 commented on code in PR #2382:
URL: https://github.com/apache/solr/pull/2382#discussion_r1602065616
##
solr/modules/monitor/src/java/org/apache/lucene/monitor/MonitorFields.java:
##
@@ -0,0 +1,38 @@
+/*
+ *
+ * * Licensed to the Apache Software Foundation (ASF) under one or more
+ * * contributor license agreements. See the NOTICE file distributed with
+ * * this work for additional information regarding copyright ownership.
+ * * The ASF licenses this file to You under the Apache License, Version 2.0
+ * * (the "License"); you may not use this file except in compliance with
+ * * the License. You may obtain a copy of the License at
+ * *
+ * * http://www.apache.org/licenses/LICENSE-2.0
+ * *
+ * * Unless required by applicable law or agreed to in writing, software
+ * * distributed under the License is distributed on an "AS IS" BASIS,
+ * * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * * See the License for the specific language governing permissions and
+ * * limitations under the License.
+ *
+ */
+
+package org.apache.lucene.monitor;
+
+import java.util.Set;
+
+public class MonitorFields {
+
+ public static final String QUERY_ID = QueryIndex.FIELDS.query_id + "_";
+ public static final String CACHE_ID = QueryIndex.FIELDS.cache_id + "_";
+ public static final String MONITOR_QUERY = QueryIndex.FIELDS.mq + "_";
+ public static final String PAYLOAD = QueryIndex.FIELDS.mq + "_payload_";
Review Comment:
So echoing one of your earlier points about limiting the scope of the
initial phase, payload is one of those things that would be on my cutting
block. Initially I tried to have something that would effectively equate to the
[optional lucene-monitor metadata
map](https://github.com/apache/lucene/blob/main/lucene/monitor/src/java/org/apache/lucene/monitor/MonitorQuery.java#L43).
I believe the point of this is to return back that metadata in case there is
something useful that you want to associate with an indexed query.
Functionally, it serves the same purpose to a stored/doc-values solr field but
in a much less flexible and less normalized way. What's funny is that I haven't
actually wired this into the response yet because I don't think any of the
default lucene-monitor responses pass it back and I was simply going for
feature parity. That aside, is there a particular reason you were exploring
making the payload field name overridable? Maybe to let users give it a more
self-descri
bing name for their particular use case?
The difference between a query decomposer and a decoder is that the
decomposer takes an in-memory `Query` object and splits it into `List`
where each element is a presumably smaller disjunct that is less expensive to
match in the final phase (think for example of an or-expression with 500 terms
.. each one of those can be indexed/matched separately for a much faster
matching phase). A query decoder simply takes the original full query string
and parses it to the original full/undecomposed `Query`. After that you have to
split it into the disjuncts again as [there is no _easy_ and _general_
way](https://stackoverflow.com/a/16966866) to serialize those inner `Query`s.
That detail aside, I don't see any reason the decoder can't use the decomposer
directly and expose that decomposition as part of its API ... this is more of
me explaining this distinction between lucene's original
`MonitorQuerySerializer` and `QueryDecomposer`.
--
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] SOLR-17275: Major performance regression of CloudSolrClient in Solr 9.6.0 when using aliases [solr]
aparnasuresh85 opened a new pull request, #2463: URL: https://github.com/apache/solr/pull/2463 https://issues.apache.org/jira/browse/SOLR-17275 # Description A recent change, as part of SOLR-17153 to ZkClusterStateProvider caused CloudSolrClient (zk based) to force update collection in local cluster state for aliases, which indeed caused a performance regression. Verified this using a test # Solution Partially reverted the change from SOLR-17153 that caused the regression (behavior on the client side should be fully reverted) # Tests Verified that all tests pass. Used a test to verify this locally, but not checking in the test since the code path changes with this commit. # Checklist Please review the following and check all that apply: - [X] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [X] I have created a Jira issue and added the issue ID to my pull request title. - [X] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [X] I have developed this patch against the `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
Re: [PR] SOLR-17106: LBSolrClient - Make zombie ping checks configurable [solr]
dsmiley commented on code in PR #2160:
URL: https://github.com/apache/solr/pull/2160#discussion_r1601881299
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBSolrClient.java:
##
@@ -480,35 +488,70 @@ public RequestWriter getRequestWriter() {
return requestWriter;
}
+ private boolean isServerAlive(ServerWrapper zombieServer)
+ throws SolrServerException, IOException {
+if (null == aliveCheckQuery) {
+ log.debug("Assuming success because aliveCheckQuery is null");
+ return true;
+}
+log.debug("Running ping check on server " + zombieServer.getBaseUrl());
+QueryRequest queryRequest = new QueryRequest(aliveCheckQuery);
+queryRequest.setBasePath(zombieServer.baseUrl);
+return
queryRequest.process(getClient(zombieServer.getBaseUrl())).getStatus() == 0;
+ }
+
+ private void handleServerBackUp(ServerWrapper zombieServer) {
+// server has come back up.
+// make sure to remove from zombies before adding to alive to avoid a race
condition
+// where another thread could mark it down, move it back to zombie, and
then we delete
+// from zombie and lose it forever.
+ServerWrapper wrapper = zombieServers.remove(zombieServer.getBaseUrl());
+if (wrapper != null) {
+ wrapper.failedPings = 0;
+ if (wrapper.standard) {
+addToAlive(wrapper);
+ }
+} else {
+ // something else already moved the server from zombie to alive
+}
+ }
+
+ private void handleServerDown(ServerWrapper zombieServer) {
+// Expected. The server is still down.
+zombieServer.failedPings++;
+zombieServer.skipAliveCheckIters = this.aliveCheckSkipIters;
+
+// If the server doesn't belong in the standard set belonging to this load
balancer
+// then simply drop it after a certain number of failed pings.
+if (!zombieServer.standard && zombieServer.failedPings >=
NONSTANDARD_PING_LIMIT) {
+ zombieServers.remove(zombieServer.getBaseUrl());
+}
+ }
+
private void checkAZombieServer(ServerWrapper zombieServer) {
try {
- QueryRequest queryRequest = new QueryRequest(solrQuery);
- queryRequest.setBasePath(zombieServer.baseUrl);
- QueryResponse resp =
queryRequest.process(getClient(zombieServer.getBaseUrl()));
- if (resp.getStatus() == 0) {
-// server has come back up.
-// make sure to remove from zombies before adding to alive to avoid a
race condition
-// where another thread could mark it down, move it back to zombie,
and then we delete
-// from zombie and lose it forever.
-ServerWrapper wrapper =
zombieServers.remove(zombieServer.getBaseUrl());
-if (wrapper != null) {
- wrapper.failedPings = 0;
- if (wrapper.standard) {
-addToAlive(wrapper);
- }
-} else {
- // something else already moved the server from zombie to alive
-}
+ // push back on liveness checks only every Nth iteration
+ if (zombieServer.skipAliveCheckIters > 0) {
+log.debug(
+"Skipping liveness check for server "
++ zombieServer.getBaseUrl()
++ " because skipAliveCheckIters = "
++ zombieServer.skipAliveCheckIters);
+zombieServer.skipAliveCheckIters--;
+return;
}
-} catch (Exception e) {
- // Expected. The server is still down.
- zombieServer.failedPings++;
- // If the server doesn't belong in the standard set belonging to this
load balancer
- // then simply drop it after a certain number of failed pings.
- if (!zombieServer.standard && zombieServer.failedPings >=
NONSTANDARD_PING_LIMIT) {
-zombieServers.remove(zombieServer.getBaseUrl());
+ if (isServerAlive(zombieServer)) {
+log.debug("Successfully pinged server " + zombieServer.getBaseUrl() +
", marking it alive");
Review Comment:
Always use "{}" templates in SLF4J
--
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-14673) Add CLI for Streaming Expressions
[
https://issues.apache.org/jira/browse/SOLR-14673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846679#comment-17846679
]
Eric Pugh commented on SOLR-14673:
--
I am poking around at the patch file to see if I can understand it ;)
> Add CLI for Streaming Expressions
> -
>
> Key: SOLR-14673
> URL: https://issues.apache.org/jira/browse/SOLR-14673
> Project: Solr
> Issue Type: New Feature
> Components: streaming expressions
>Reporter: Joel Bernstein
>Assignee: Joel Bernstein
>Priority: Major
> Attachments: SOLR-14673.patch, SOLR-14673.patch, SOLR-14673.patch,
> SOLR-14673.patch, SOLR-14673.patch
>
>
> This ticket will provide a simple CLI that will run a Streaming Expression
> from the command line and return the results as a delimited result set. This
> will allow Streaming Expressions to be used from the command line to extract
> data as well as load data into Solr.
> Sample syntax:
> {code:java}
> bin/expr expr_file{code}
> This will run the expression in _expr_file_.
> Output will be to standard out as delimited records.
> *Standard-In, Standard-out and Pipe Composition.*
> The CLI can read from *standard-in* and write to *standard-out* in delimited
> records. This allows Streaming Expressions to be composed using unix pipes
> with other command line tools and other streaming expressions. Example syntax:
> {code:java}
> cat data.csv | ./bin/expr load.expr {code}
> The load.expr file uses the *stndin()* function to read from standard-in and
> load date to Solr. Here is a sample load.expr
> {code:java}
> let(cli-zkhost="localhost:9983",
>
> update(collection1,
>parseCSV(stndin()))
> {code}
> In the example above the *let* expression is used to set the *cli-zkhost* and
> then run the Streaming Expression:
> {code:java}
> update(collection1,
>parseCSV(stndin()){code}
> The *stndin* function reads the data from standard-in. The *parseCSV*
> function parses the lines into tuples and the *update* function sends the
> data to collection1 for indexing.
>
> *Querying Solr and Pipe Composition*
> The CLI can also be used to query Solr and pipe the result to other
> applications on the command line. This can automate activities like alerting,
> data backup, replication etc...
>
>
>
>
--
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-4587: integrate lucene-monitor into solr [solr]
cpoerschke commented on code in PR #2382:
URL: https://github.com/apache/solr/pull/2382#discussion_r1601740654
##
solr/modules/monitor/src/java/org/apache/lucene/monitor/MonitorFields.java:
##
@@ -0,0 +1,38 @@
+/*
+ *
+ * * Licensed to the Apache Software Foundation (ASF) under one or more
+ * * contributor license agreements. See the NOTICE file distributed with
+ * * this work for additional information regarding copyright ownership.
+ * * The ASF licenses this file to You under the Apache License, Version 2.0
+ * * (the "License"); you may not use this file except in compliance with
+ * * the License. You may obtain a copy of the License at
+ * *
+ * * http://www.apache.org/licenses/LICENSE-2.0
+ * *
+ * * Unless required by applicable law or agreed to in writing, software
+ * * distributed under the License is distributed on an "AS IS" BASIS,
+ * * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * * See the License for the specific language governing permissions and
+ * * limitations under the License.
+ *
+ */
+
+package org.apache.lucene.monitor;
+
+import java.util.Set;
+
+public class MonitorFields {
+
+ public static final String QUERY_ID = QueryIndex.FIELDS.query_id + "_";
+ public static final String CACHE_ID = QueryIndex.FIELDS.cache_id + "_";
+ public static final String MONITOR_QUERY = QueryIndex.FIELDS.mq + "_";
+ public static final String PAYLOAD = QueryIndex.FIELDS.mq + "_payload_";
Review Comment:
The
https://github.com/cpoerschke/solr/commit/26f932bc077cc2fc1abd553480e9efe715a6f7c5
commit on https://github.com/cpoerschke/solr/commits/solr-monitor-cpoerschke-3
explores turning the `MonitorFields.PAYLOAD` constant into a configurable.
And interesting insight from that is the co-occurrence of
`org.apache.lucene.monitor.QueryDecomposer` and `String payloadFieldName` --
not yet explored if maybe inheritance might be a thing.
```
class SolrQueryDecomposer extends org.apache.lucene.monitor.QueryDecomposer {
String payloadFieldName;
}
```
Also (note-to-self) looking to understand further w.r.t. query decomposer
vs. query decoder and how the field names fit into that picture.
--
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-17106: LBSolrClient - Make zombie ping checks configurable [solr]
epugh commented on code in PR #2160:
URL: https://github.com/apache/solr/pull/2160#discussion_r1601674762
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttp2SolrClient.java:
##
@@ -281,6 +298,37 @@ public LBHttp2SolrClient.Builder setAliveCheckInterval(int
aliveCheckInterval, T
return this;
}
+/**
+ * Positive values can be used to ensure that the liveness checks for a
given URL will only be
+ * run every "Nth" iteration of the setAliveCheckInterval
+ *
+ * @param aliveCheckSkipIters, number of iterations to skip, an int value *
Review Comment:
did this mean to have a trailing `*`?
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBSolrClient.java:
##
@@ -480,35 +488,70 @@ public RequestWriter getRequestWriter() {
return requestWriter;
}
+ private boolean isServerAlive(ServerWrapper zombieServer)
+ throws SolrServerException, IOException {
+if (null == aliveCheckQuery) {
+ log.debug("Assuming success because aliveCheckQuery is null");
+ return true;
+}
+log.debug("Running ping check on server " + zombieServer.getBaseUrl());
+QueryRequest queryRequest = new QueryRequest(aliveCheckQuery);
+queryRequest.setBasePath(zombieServer.baseUrl);
+return
queryRequest.process(getClient(zombieServer.getBaseUrl())).getStatus() == 0;
+ }
+
+ private void handleServerBackUp(ServerWrapper zombieServer) {
+// server has come back up.
+// make sure to remove from zombies before adding to alive to avoid a race
condition
+// where another thread could mark it down, move it back to zombie, and
then we delete
+// from zombie and lose it forever.
+ServerWrapper wrapper = zombieServers.remove(zombieServer.getBaseUrl());
+if (wrapper != null) {
+ wrapper.failedPings = 0;
+ if (wrapper.standard) {
+addToAlive(wrapper);
+ }
+} else {
+ // something else already moved the server from zombie to alive
+}
+ }
+
+ private void handleServerDown(ServerWrapper zombieServer) {
+// Expected. The server is still down.
+zombieServer.failedPings++;
+zombieServer.skipAliveCheckIters = this.aliveCheckSkipIters;
+
+// If the server doesn't belong in the standard set belonging to this load
balancer
+// then simply drop it after a certain number of failed pings.
+if (!zombieServer.standard && zombieServer.failedPings >=
NONSTANDARD_PING_LIMIT) {
+ zombieServers.remove(zombieServer.getBaseUrl());
+}
+ }
+
private void checkAZombieServer(ServerWrapper zombieServer) {
try {
- QueryRequest queryRequest = new QueryRequest(solrQuery);
- queryRequest.setBasePath(zombieServer.baseUrl);
- QueryResponse resp =
queryRequest.process(getClient(zombieServer.getBaseUrl()));
- if (resp.getStatus() == 0) {
-// server has come back up.
-// make sure to remove from zombies before adding to alive to avoid a
race condition
-// where another thread could mark it down, move it back to zombie,
and then we delete
-// from zombie and lose it forever.
-ServerWrapper wrapper =
zombieServers.remove(zombieServer.getBaseUrl());
-if (wrapper != null) {
- wrapper.failedPings = 0;
- if (wrapper.standard) {
-addToAlive(wrapper);
- }
-} else {
- // something else already moved the server from zombie to alive
-}
+ // push back on liveness checks only every Nth iteration
+ if (zombieServer.skipAliveCheckIters > 0) {
+log.debug(
+"Skipping liveness check for server "
++ zombieServer.getBaseUrl()
++ " because skipAliveCheckIters = "
++ zombieServer.skipAliveCheckIters);
+zombieServer.skipAliveCheckIters--;
+return;
}
-} catch (Exception e) {
- // Expected. The server is still down.
- zombieServer.failedPings++;
- // If the server doesn't belong in the standard set belonging to this
load balancer
- // then simply drop it after a certain number of failed pings.
- if (!zombieServer.standard && zombieServer.failedPings >=
NONSTANDARD_PING_LIMIT) {
-zombieServers.remove(zombieServer.getBaseUrl());
+ if (isServerAlive(zombieServer)) {
+log.debug("Successfully pinged server " + zombieServer.getBaseUrl() +
", marking it alive");
Review Comment:
and the check
##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/LBHttpSolrClient.java:
##
@@ -266,19 +280,49 @@ public Builder withBaseSolrUrls(String... solrUrls) {
/**
* LBHttpSolrServer keeps pinging the dead servers at fixed interval to
find if it is alive. Use
- * this to set that interval
- *
- * @param aliveCheckInterval time in milliseconds
+ * this to set that interval.
+ * @param aliveCheckInterval how often to ping for aliveness
+ * @see
[jira] [Commented] (SOLR-17263) HttpJdkSolrClient doesn't encode curly braces etc
[
https://issues.apache.org/jira/browse/SOLR-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846638#comment-17846638
]
David Smiley commented on SOLR-17263:
-
I'm a bit confused by all these PRs but I merged the first one to main,
branch_9x, and branch_9_6 as the comments above show. Maybe someone else can
help out with the others.
> HttpJdkSolrClient doesn't encode curly braces etc
> -
>
> Key: SOLR-17263
> URL: https://issues.apache.org/jira/browse/SOLR-17263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.6.0
>Reporter: Andy Webb
>Priority: Major
> Fix For: 9.6.1
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Ref
> https://issues.apache.org/jira/browse/SOLR-599?focusedCommentId=17842429#comment-17842429
> - {{HttpJdkSolrClient}} should use {{{}SolrParams{}}}' {{toQueryString()}}
> method when constructing URLs to that all URL-unsafe characters are encoded.
> It's implicitly using the {{toString()}} method currently which is intended
> for logging etc purposes.
> Attempting to use alternate query parsers in requests as shown below will
> currently fail as the curly braces aren't encoded.
> {noformat}
> myquery.set("fq", "{!terms f=myfield}value1,value2"); {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
Re: [PR] SOLR-17106: LBSolrClient - Make zombie ping checks configurable [solr]
dsmiley commented on PR #2160: URL: https://github.com/apache/solr/pull/2160#issuecomment-2112567149 Aparna, are we just missing use of EnvUtils here? I know we've taken this change as-is (in our fork) but even we don't have that, thus it's hard to actually _use_ the changes configured 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
[jira] [Commented] (SOLR-17263) HttpJdkSolrClient doesn't encode curly braces etc
[
https://issues.apache.org/jira/browse/SOLR-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846634#comment-17846634
]
ASF subversion and git services commented on SOLR-17263:
Commit aafdb1be43c2173a1ef757b858d5027e83bd2d89 in solr's branch
refs/heads/branch_9_6 from Andy Webb
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=aafdb1be43c ]
SOLR-17263: HttpJdkSolrClient doesn't encode curly braces etc (#2433)
(cherry picked from commit 4c439d07ca35e7e80c5406c103e885307f0b64b9)
> HttpJdkSolrClient doesn't encode curly braces etc
> -
>
> Key: SOLR-17263
> URL: https://issues.apache.org/jira/browse/SOLR-17263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.6.0
>Reporter: Andy Webb
>Priority: Major
> Fix For: 9.6.1
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Ref
> https://issues.apache.org/jira/browse/SOLR-599?focusedCommentId=17842429#comment-17842429
> - {{HttpJdkSolrClient}} should use {{{}SolrParams{}}}' {{toQueryString()}}
> method when constructing URLs to that all URL-unsafe characters are encoded.
> It's implicitly using the {{toString()}} method currently which is intended
> for logging etc purposes.
> Attempting to use alternate query parsers in requests as shown below will
> currently fail as the curly braces aren't encoded.
> {noformat}
> myquery.set("fq", "{!terms f=myfield}value1,value2"); {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
Re: [PR] SOLR-17109: Give security manager explicit read access to sharedLib [solr]
epugh commented on PR #2172: URL: https://github.com/apache/solr/pull/2172#issuecomment-2112502657 > I'm fine with merging this. @janhoy's comment is valid though, it would cause issues if `solr.sharedLib` has more than one directory do you want me to do it? Or I can leave it up to you. I just love seeing PR's and tickets close ;-) -- 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] SOLR-16505: Add auth listener to recovery client [solr]
iamsanjay opened a new pull request, #2462: URL: https://github.com/apache/solr/pull/2462 https://issues.apache.org/jira/browse/SOLR-16505 As previously noticed that whenever we re-create Solr client using existing `Http2SolrClient` then no listeners were passed to the new `Http2SolrClient` object. To fix this, a new code(`withListenerFactory` method in `Http2SolrClient#Builder` class) is added to previous commit for SOLR_16505. However, It did not called this new method for client in RecoveryStrategy. Therefore all the calls that were made from RecoveryStrategy were failing in case if auth is enabled. # Tests A new test case is added to configure SolrCloud with a security.json file. A specific test condition is tested where after indexing good amount of document, a new replica is added which would trigger RecoveryStrategy for it and everything is happening when auth is enabled. # Checklist Please review the following and check all that apply: - [x] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [x] I have created a Jira issue and added the issue ID to my pull request title. - [x] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended) - [x] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. - [x] 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
Re: [PR] SOLR-17109: Give security manager explicit read access to sharedLib [solr]
tflobbe commented on PR #2172: URL: https://github.com/apache/solr/pull/2172#issuecomment-2112460299 I'm fine with merging this. @janhoy's comment is valid though, it would cause issues if `solr.sharedLib` has more than one directory -- 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-17263) HttpJdkSolrClient doesn't encode curly braces etc
[
https://issues.apache.org/jira/browse/SOLR-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846620#comment-17846620
]
ASF subversion and git services commented on SOLR-17263:
Commit be9fcf3d696b2ac484f128a58561c2cf942eaf5b in solr's branch
refs/heads/branch_9x from Andy Webb
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=be9fcf3d696 ]
SOLR-17263: HttpJdkSolrClient doesn't encode curly braces etc (#2433)
(cherry picked from commit 4c439d07ca35e7e80c5406c103e885307f0b64b9)
> HttpJdkSolrClient doesn't encode curly braces etc
> -
>
> Key: SOLR-17263
> URL: https://issues.apache.org/jira/browse/SOLR-17263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.6.0
>Reporter: Andy Webb
>Priority: Major
> Fix For: 9.6.1
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Ref
> https://issues.apache.org/jira/browse/SOLR-599?focusedCommentId=17842429#comment-17842429
> - {{HttpJdkSolrClient}} should use {{{}SolrParams{}}}' {{toQueryString()}}
> method when constructing URLs to that all URL-unsafe characters are encoded.
> It's implicitly using the {{toString()}} method currently which is intended
> for logging etc purposes.
> Attempting to use alternate query parsers in requests as shown below will
> currently fail as the curly braces aren't encoded.
> {noformat}
> myquery.set("fq", "{!terms f=myfield}value1,value2"); {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] [Commented] (SOLR-17263) HttpJdkSolrClient doesn't encode curly braces etc
[
https://issues.apache.org/jira/browse/SOLR-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846619#comment-17846619
]
ASF subversion and git services commented on SOLR-17263:
Commit 4c439d07ca35e7e80c5406c103e885307f0b64b9 in solr's branch
refs/heads/main from Andy Webb
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=4c439d07ca3 ]
SOLR-17263: HttpJdkSolrClient doesn't encode curly braces etc (#2433)
> HttpJdkSolrClient doesn't encode curly braces etc
> -
>
> Key: SOLR-17263
> URL: https://issues.apache.org/jira/browse/SOLR-17263
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrJ
>Affects Versions: 9.6.0
>Reporter: Andy Webb
>Priority: Major
> Fix For: 9.6.1
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Ref
> https://issues.apache.org/jira/browse/SOLR-599?focusedCommentId=17842429#comment-17842429
> - {{HttpJdkSolrClient}} should use {{{}SolrParams{}}}' {{toQueryString()}}
> method when constructing URLs to that all URL-unsafe characters are encoded.
> It's implicitly using the {{toString()}} method currently which is intended
> for logging etc purposes.
> Attempting to use alternate query parsers in requests as shown below will
> currently fail as the curly braces aren't encoded.
> {noformat}
> myquery.set("fq", "{!terms f=myfield}value1,value2"); {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
Re: [PR] SOLR-17263: HttpJdkSolrClient doesn't encode curly braces etc [solr]
dsmiley merged PR #2433: URL: https://github.com/apache/solr/pull/2433 -- 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-17109: Give security manager explicit read access to sharedLib [solr]
epugh commented on PR #2172: URL: https://github.com/apache/solr/pull/2172#issuecomment-2112425839 Also, @dsmiley looks like you approved this change, can we go ahead and get it 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
Re: [PR] SOLR-17109: Give security manager explicit read access to sharedLib [solr]
epugh commented on PR #2172: URL: https://github.com/apache/solr/pull/2172#issuecomment-2112421629 Can someone explain the future of security manager in Java to me? My understanding is that it is going away (and no replacement??)... So, wouldn't it be better just to deprecate the security manager now, and NOT rely on 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] [Reopened] (SOLR-16505) Switch UpdateShardHandler.getRecoveryOnlyHttpClient to Jetty HTTP2
[ https://issues.apache.org/jira/browse/SOLR-16505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley reopened SOLR-16505: - Assignee: David Smiley > Switch UpdateShardHandler.getRecoveryOnlyHttpClient to Jetty HTTP2 > -- > > Key: SOLR-16505 > URL: https://issues.apache.org/jira/browse/SOLR-16505 > Project: Solr > Issue Type: Sub-task >Reporter: David Smiley >Assignee: David Smiley >Priority: Major > Fix For: 9.7 > > Time Spent: 8.5h > Remaining Estimate: 0h > > This method and its callers (only RecoveryStrategy) should be converted to a > Jetty HTTP2 client. -- 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-17290: Update SyncStrategy and PeerSyncWithLeader to use the recovery Http2SolrClient [solr]
epugh commented on PR #2460: URL: https://github.com/apache/solr/pull/2460#issuecomment-2112418592 Would love some thoughts on how we could handle the auth scenarios better without having to write an explicit test for it on every piece of code, once with auth and once with out ;-) -- 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-17290: Update SyncStrategy and PeerSyncWithLeader to use the recovery Http2SolrClient [solr]
iamsanjay commented on PR #2460: URL: https://github.com/apache/solr/pull/2460#issuecomment-2112288509 > +1; will merge tomorrow. > > > The solr client is being used for REQUESTRECOVERY and did not seem to need the auth for that. > > Maybe you know something I don't here; what technical mechanism doesn't happen for recovery for auth? AFAIK all Solr-to-Solr communication needs to support AuthenticationPlugin. And I believe it is == see `org.apache.solr.update.UpdateShardHandler#setSecurityBuilder` invoked by the auth plugin initialization and that which configures the update & recovery clients. I found a bug in SOLR-16505! RecoveryStrategy is using a client without auth listener. It did not failed because, i believe, there is no specific test for Recovery where SolrCloud is configured along with Security.json. Going to submit PR today for a fix. @dsmiley Please open again SOLR-16505. -- 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-4587: integrate lucene-monitor into solr [solr]
cpoerschke commented on code in PR #2382:
URL: https://github.com/apache/solr/pull/2382#discussion_r1601387931
##
solr/modules/monitor/src/java/org/apache/solr/monitor/update/MonitorUpdateRequestProcessor.java:
##
@@ -0,0 +1,257 @@
+/*
+ *
+ * * 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.monitor.update;
+
+import java.io.IOException;
+import java.io.Reader;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.Optional;
+import java.util.stream.Collectors;
+import java.util.stream.Stream;
+import org.apache.lucene.analysis.Analyzer;
+import org.apache.lucene.analysis.TokenStream;
+import org.apache.lucene.document.Document;
+import org.apache.lucene.document.Field;
+import org.apache.lucene.document.InvertableType;
+import org.apache.lucene.document.StoredValue;
+import org.apache.lucene.index.DocValuesType;
+import org.apache.lucene.index.IndexableField;
+import org.apache.lucene.index.IndexableFieldType;
+import org.apache.lucene.monitor.MonitorFields;
+import org.apache.lucene.monitor.MonitorQuery;
+import org.apache.lucene.monitor.Presearcher;
+import org.apache.lucene.monitor.QCEVisitor;
+import org.apache.lucene.util.BytesRef;
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.SolrInputDocument;
+import org.apache.solr.common.util.JavaBinCodec;
+import org.apache.solr.core.SolrCore;
+import org.apache.solr.monitor.MonitorConstants;
+import org.apache.solr.monitor.MonitorSchemaFields;
+import org.apache.solr.monitor.SimpleQueryParser;
+import org.apache.solr.schema.IndexSchema;
+import org.apache.solr.schema.SchemaField;
+import org.apache.solr.update.AddUpdateCommand;
+import org.apache.solr.update.processor.UpdateRequestProcessor;
+
+public class MonitorUpdateRequestProcessor extends UpdateRequestProcessor {
+
+ private final SolrCore core;
+ private final IndexSchema indexSchema;
+ private final Presearcher presearcher;
+ private final MonitorSchemaFields monitorSchemaFields;
+
+ public MonitorUpdateRequestProcessor(
+ UpdateRequestProcessor next, SolrCore core, Presearcher presearcher) {
+super(next);
+this.core = core;
+this.indexSchema = core.getLatestSchema();
+this.presearcher = presearcher;
+this.monitorSchemaFields = new MonitorSchemaFields(indexSchema);
+ }
+
+ @Override
+ public void processAdd(AddUpdateCommand cmd) throws IOException {
+var solrInputDocument = cmd.getSolrInputDocument();
+var queryId =
+(String)
solrInputDocument.getFieldValue(indexSchema.getUniqueKeyField().getName());
+var queryFieldValue =
solrInputDocument.getFieldValue(MonitorFields.MONITOR_QUERY);
+if (queryFieldValue != null) {
+ var payload =
+
Optional.ofNullable(solrInputDocument.getFieldValue(MonitorFields.PAYLOAD))
+ .map(Object::toString)
+ .orElse(null);
+ List children =
+ Optional.of(queryFieldValue)
+ .filter(String.class::isInstance)
+ .map(String.class::cast)
+ .map(
+ queryStr ->
+ new MonitorQuery(
+ queryId, SimpleQueryParser.parse(queryStr, core),
queryStr, Map.of()))
+ .stream()
+ .flatMap(monitorQuery -> decompose(monitorQuery, payload))
+ .map(this::toSolrInputDoc)
+ .collect(Collectors.toList());
+ if (children.isEmpty()) {
+throw new SolrException(
+SolrException.ErrorCode.INVALID_STATE, "Query could not be
decomposed");
+ }
+ SolrInputDocument firstChild = children.get(0);
+ if (solrInputDocument.hasChildDocuments()) {
+solrInputDocument.getChildDocuments().clear();
+ }
+
solrInputDocument.addChildDocuments(children.stream().skip(1).collect(Collectors.toList()));
+ if (solrInputDocument.hasChildDocuments()) {
+solrInputDocument
+.getChildDocuments()
+.forEach(
+child ->
+solrInputDocument.forEach(
+field -> {
+ if
Re: [PR] SOLR-4587: integrate lucene-monitor into solr [solr]
cpoerschke commented on code in PR #2382:
URL: https://github.com/apache/solr/pull/2382#discussion_r1601379272
##
solr/modules/monitor/src/java/org/apache/solr/monitor/update/MonitorUpdateRequestProcessor.java:
##
@@ -0,0 +1,257 @@
+/*
+ *
+ * * 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.monitor.update;
+
+import java.io.IOException;
+import java.io.Reader;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Map;
+import java.util.Optional;
+import java.util.stream.Collectors;
+import java.util.stream.Stream;
+import org.apache.lucene.analysis.Analyzer;
+import org.apache.lucene.analysis.TokenStream;
+import org.apache.lucene.document.Document;
+import org.apache.lucene.document.Field;
+import org.apache.lucene.document.InvertableType;
+import org.apache.lucene.document.StoredValue;
+import org.apache.lucene.index.DocValuesType;
+import org.apache.lucene.index.IndexableField;
+import org.apache.lucene.index.IndexableFieldType;
+import org.apache.lucene.monitor.MonitorFields;
+import org.apache.lucene.monitor.MonitorQuery;
+import org.apache.lucene.monitor.Presearcher;
+import org.apache.lucene.monitor.QCEVisitor;
+import org.apache.lucene.util.BytesRef;
+import org.apache.solr.common.SolrException;
+import org.apache.solr.common.SolrInputDocument;
+import org.apache.solr.common.util.JavaBinCodec;
+import org.apache.solr.core.SolrCore;
+import org.apache.solr.monitor.MonitorConstants;
+import org.apache.solr.monitor.MonitorSchemaFields;
+import org.apache.solr.monitor.SimpleQueryParser;
+import org.apache.solr.schema.IndexSchema;
+import org.apache.solr.schema.SchemaField;
+import org.apache.solr.update.AddUpdateCommand;
+import org.apache.solr.update.processor.UpdateRequestProcessor;
+
+public class MonitorUpdateRequestProcessor extends UpdateRequestProcessor {
+
+ private final SolrCore core;
+ private final IndexSchema indexSchema;
+ private final Presearcher presearcher;
+ private final MonitorSchemaFields monitorSchemaFields;
+
+ public MonitorUpdateRequestProcessor(
+ UpdateRequestProcessor next, SolrCore core, Presearcher presearcher) {
+super(next);
+this.core = core;
+this.indexSchema = core.getLatestSchema();
+this.presearcher = presearcher;
+this.monitorSchemaFields = new MonitorSchemaFields(indexSchema);
+ }
+
+ @Override
+ public void processAdd(AddUpdateCommand cmd) throws IOException {
+var solrInputDocument = cmd.getSolrInputDocument();
+var queryId =
+(String)
solrInputDocument.getFieldValue(indexSchema.getUniqueKeyField().getName());
+var queryFieldValue =
solrInputDocument.getFieldValue(MonitorFields.MONITOR_QUERY);
+if (queryFieldValue != null) {
+ var payload =
+
Optional.ofNullable(solrInputDocument.getFieldValue(MonitorFields.PAYLOAD))
+ .map(Object::toString)
+ .orElse(null);
+ List children =
+ Optional.of(queryFieldValue)
+ .filter(String.class::isInstance)
+ .map(String.class::cast)
+ .map(
+ queryStr ->
+ new MonitorQuery(
+ queryId, SimpleQueryParser.parse(queryStr, core),
queryStr, Map.of()))
+ .stream()
+ .flatMap(monitorQuery -> decompose(monitorQuery, payload))
+ .map(this::toSolrInputDoc)
+ .collect(Collectors.toList());
+ if (children.isEmpty()) {
+throw new SolrException(
+SolrException.ErrorCode.INVALID_STATE, "Query could not be
decomposed");
+ }
+ SolrInputDocument firstChild = children.get(0);
+ if (solrInputDocument.hasChildDocuments()) {
+solrInputDocument.getChildDocuments().clear();
+ }
+
solrInputDocument.addChildDocuments(children.stream().skip(1).collect(Collectors.toList()));
+ if (solrInputDocument.hasChildDocuments()) {
+solrInputDocument
+.getChildDocuments()
+.forEach(
+child ->
+solrInputDocument.forEach(
+field -> {
+ if
[I] Solr 8.11 with SolrMetrics produces duplicate samples with prometheus v2.52 [solr-operator]
perosb opened a new issue, #705:
URL: https://github.com/apache/solr-operator/issues/705
Solr 8.11 seem to be producing duplicate metrics which is flooding the logs
and triggering alerts.
This is only when using latest prometheus v2.52.0. Related
https://github.com/prometheus/prometheus/issues/14089
This doesn't seem to happen with Solr 9.
It still happens when running solr 8.11 and solr-exporter image tag 9.x
This is the debug log with 1 collection and the related duplicates:
```
{"caller":"scrape.go:1777","component":"scrape
manager","level":"debug","msg":"Duplicate sample for
timestamp","scrape_pool":"serviceMonitor/solr-test/solr-metrics/0","series":"solr_metrics_core_query_requests_total{category=\"QUERY\",searchHandler=\"/select\",internal=\"false\",core=\"kermit_shard1_replica_n1\",collection=\"kermit\",shard=\"shard1\",replica=\"replica_n1\",base_url=\"http://frog-solrcloud-1.frog-solrcloud-headless.solr-test:8983/solr\",cluster_id=\"f7122eee5d\"}","target":"http://172.23.50.53:8080/metrics","ts":"2024-05-15T08:32:26.909Z"}
{"caller":"scrape.go:1777","component":"scrape
manager","level":"debug","msg":"Duplicate sample for
timestamp","scrape_pool":"serviceMonitor/solr-test/solr-metrics/0","series":"solr_metrics_core_query_mean_rate{category=\"QUERY\",searchHandler=\"/select\",internal=\"false\",core=\"kermit_shard1_replica_n1\",collection=\"kermit\",shard=\"shard1\",replica=\"replica_n1\",base_url=\"http://frog-solrcloud-1.frog-solrcloud-headless.solr-test:8983/solr\",cluster_id=\"f7122eee5d\"}","target":"http://172.23.50.53:8080/metrics","ts":"2024-05-15T08:32:26.909Z"}
{"caller":"scrape.go:1777","component":"scrape
manager","level":"debug","msg":"Duplicate sample for
timestamp","scrape_pool":"serviceMonitor/solr-test/solr-metrics/0","series":"solr_metrics_core_query_mean_rate{category=\"QUERY\",searchHandler=\"/select\",internal=\"false\",core=\"kermit_shard1_replica_n1\",collection=\"kermit\",shard=\"shard1\",replica=\"replica_n1\",base_url=\"http://frog-solrcloud-1.frog-solrcloud-headless.solr-test:8983/solr\",cluster_id=\"f7122eee5d\"}","target":"http://172.23.50.53:8080/metrics","ts":"2024-05-15T08:32:26.909Z"}
{"caller":"scrape.go:1777","component":"scrape
manager","level":"debug","msg":"Duplicate sample for
timestamp","scrape_pool":"serviceMonitor/solr-test/solr-metrics/0","series":"solr_metrics_core_query_5minRate{category=\"QUERY\",searchHandler=\"/select\",internal=\"false\",core=\"kermit_shard1_replica_n1\",collection=\"kermit\",shard=\"shard1\",replica=\"replica_n1\",base_url=\"http://frog-solrcloud-1.frog-solrcloud-headless.solr-test:8983/solr\",cluster_id=\"f7122eee5d\"}","target":"http://172.23.50.53:8080/metrics","ts":"2024-05-15T08:32:26.909Z"}
{"caller":"scrape.go:1777","component":"scrape
manager","level":"debug","msg":"Duplicate sample for
timestamp","scrape_pool":"serviceMonitor/solr-test/solr-metrics/0","series":"solr_metrics_core_query_1minRate{category=\"QUERY\",searchHandler=\"/select\",internal=\"false\",core=\"kermit_shard1_replica_n1\",collection=\"kermit\",shard=\"shard1\",replica=\"replica_n1\",base_url=\"http://frog-solrcloud-1.frog-solrcloud-headless.solr-test:8983/solr\",cluster_id=\"f7122eee5d\"}","target":"http://172.23.50.53:8080/metrics","ts":"2024-05-15T08:32:26.909Z"}
{"caller":"scrape.go:1777","component":"scrape
manager","level":"debug","msg":"Duplicate sample for
timestamp","scrape_pool":"serviceMonitor/solr-test/solr-metrics/0","series":"solr_metrics_core_query_p75_ms{category=\"QUERY\",searchHandler=\"/select\",internal=\"false\",core=\"kermit_shard1_replica_n1\",collection=\"kermit\",shard=\"shard1\",replica=\"replica_n1\",base_url=\"http://frog-solrcloud-1.frog-solrcloud-headless.solr-test:8983/solr\",cluster_id=\"f7122eee5d\"}","target":"http://172.23.50.53:8080/metrics","ts":"2024-05-15T08:32:26.909Z"}
{"caller":"scrape.go:1777","component":"scrape
manager","level":"debug","msg":"Duplicate sample for
timestamp","scrape_pool":"serviceMonitor/solr-test/solr-metrics/0","series":"solr_metrics_core_query_p75_ms{category=\"QUERY\",searchHandler=\"/select\",internal=\"false\",core=\"kermit_shard1_replica_n1\",collection=\"kermit\",shard=\"shard1\",replica=\"replica_n1\",base_url=\"http://frog-solrcloud-1.frog-solrcloud-headless.solr-test:8983/solr\",cluster_id=\"f7122eee5d\"}","target":"http://172.23.50.53:8080/metrics","ts":"2024-05-15T08:32:26.909Z"}
{"caller":"scrape.go:1777","component":"scrape
manager","level":"debug","msg":"Duplicate sample for
