[jira] [Commented] (SOLR-17342) Comply with ASF website policy - external resources
[
https://issues.apache.org/jira/browse/SOLR-17342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921732#comment-17921732
]
Jan Høydahl commented on SOLR-17342:
I can confirm that the ASF web site compliance checker now is 100% green for
Solr, for the first time in years :)
But I guess the checker does not check every page of our site, else it would
have discovered the artifacthub script tag...
!Skjermbilde 2025-01-28 kl. 14.26.58.png|width=834,height=311!
> Comply with ASF website policy - external resources
> ---
>
> Key: SOLR-17342
> URL: https://issues.apache.org/jira/browse/SOLR-17342
> Project: Solr
> Issue Type: New Feature
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Labels: pull-request-available
> Attachments: Skjermbilde 2025-01-23 kl. 11.08.23.png, Skjermbilde
> 2025-01-28 kl. 14.26.58.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The only website policy solr violates is linking to external resources:
> [https://whimsy.apache.org/site/project/solr]
> We should copy resources to our template instead of linking. The ones we link
> to in _css.html are:
>
> {code:java}
> rel='stylesheet' type='text/css'>
> href="//maxcdn.bootstrapcdn.com/font-awesome/4.1.0/css/font-awesome.min.css"
> rel="stylesheet">
> href="//cdn.jsdelivr.net/jquery.slick/1.3.7/slick.css"/> {code}
> Note that the links are in multiple files.
>
--
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-17342) Comply with ASF website policy - external resources
[
https://issues.apache.org/jira/browse/SOLR-17342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921779#comment-17921779
]
Houston Putman commented on SOLR-17342:
---
Thanks for handling this Jan!
For now, let's just comment out the artifact hub script tag and div. I spent a
few hours trying to get it local, but I can't dedicate too much more right now.
Easier to add it back in when we have time to do it.
> Comply with ASF website policy - external resources
> ---
>
> Key: SOLR-17342
> URL: https://issues.apache.org/jira/browse/SOLR-17342
> Project: Solr
> Issue Type: New Feature
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Labels: pull-request-available
> Attachments: Skjermbilde 2025-01-23 kl. 11.08.23.png, Skjermbilde
> 2025-01-28 kl. 14.26.58.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The only website policy solr violates is linking to external resources:
> [https://whimsy.apache.org/site/project/solr]
> We should copy resources to our template instead of linking. The ones we link
> to in _css.html are:
>
> {code:java}
> rel='stylesheet' type='text/css'>
> href="//maxcdn.bootstrapcdn.com/font-awesome/4.1.0/css/font-awesome.min.css"
> rel="stylesheet">
> href="//cdn.jsdelivr.net/jquery.slick/1.3.7/slick.css"/> {code}
> Note that the links are in multiple files.
>
--
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-17447 : Support to early terminate a search based on maxHits per collector. [solr]
HoustonPutman commented on code in PR #2960: URL: https://github.com/apache/solr/pull/2960#discussion_r1932439155 ## solr/solr-ref-guide/modules/query-guide/pages/common-query-parameters.adoc: ## @@ -399,6 +399,22 @@ For example, setting `cpuAllowed=500` gives a limit of at most 500 ms of CPU tim All other considerations regarding partial results listed for the `timeAllowed` parameter apply here, too. + +== maxHits Parameter + +[%autowidth,frame=none] +|=== +|Optional |Default: `false` +|=== + +This parameter specifies the max number of hits a searcher will iterate through before early terminating the search. +The count is per shard and across all threads involved in case of multi-threaded search. This parameter works +in conjunction with other parameters that could early terminate a search, ex: _timeAllowed_ etc. In case the search +was early terminated due to it exceeding maxHits a _terminatedEarly_ header in the response will be set along with +_partialResults_ to indicate the same +Note : the hits counted will need not be exactly equal to the maxHits provided, however it will be within range of this value. Review Comment: Can you explain here when the user would see partial results? The user will probably not be very familiar with how Lucene or the searcher works, so it should be from their point of view. -- 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-17447 : Support to early terminate a search based on maxHits per collector. [solr]
HoustonPutman commented on code in PR #2960:
URL: https://github.com/apache/solr/pull/2960#discussion_r1932441426
##
solr/core/src/java/org/apache/solr/search/QueryCommand.java:
##
@@ -194,7 +195,7 @@ public QueryCommand setNeedDocSet(boolean needDocSet) {
}
public boolean getTerminateEarly() {
-return (flags & SolrIndexSearcher.TERMINATE_EARLY) != 0;
+return (flags & SolrIndexSearcher.TERMINATE_EARLY) != 0 || maxHits <
Integer.MAX_VALUE;
Review Comment:
I agree, the name of the param does not really indicate that it could lead
to partial results.
--
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] remove deprecated (DocValues,Norms)FieldExistsQuery use [solr]
HoustonPutman commented on code in PR #2632: URL: https://github.com/apache/solr/pull/2632#discussion_r1932707839 ## solr/core/src/java/org/apache/solr/schema/CurrencyFieldType.java: ## @@ -387,7 +386,7 @@ private Query getRangeQueryInternal( (p1 != null) ? p1.getCurrencyCode() : (p2 != null) ? p2.getCurrencyCode() : defaultCurrency; // ValueSourceRangeFilter doesn't check exists(), so we have to -final Query docsWithValues = new DocValuesFieldExistsQuery(getAmountField(field).getName()); +final Query docsWithValues = getAmountField(field).getType().getExistenceQuery(parser, field); Review Comment: Just debugged this, stupid error. Should be passing the amountField into the method instead of the currencyField. -- 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] remove deprecated (DocValues,Norms)FieldExistsQuery use [solr]
cpoerschke commented on code in PR #2632: URL: https://github.com/apache/solr/pull/2632#discussion_r1932657684 ## solr/core/src/java/org/apache/solr/schema/CurrencyFieldType.java: ## @@ -387,7 +386,7 @@ private Query getRangeQueryInternal( (p1 != null) ? p1.getCurrencyCode() : (p2 != null) ? p2.getCurrencyCode() : defaultCurrency; // ValueSourceRangeFilter doesn't check exists(), so we have to -final Query docsWithValues = new DocValuesFieldExistsQuery(getAmountField(field).getName()); +final Query docsWithValues = getAmountField(field).getType().getExistenceQuery(parser, field); Review Comment: Able to reproduce the `./gradlew test --tests CurrencyFieldTypeTest` test failure locally, shall we go back to `FieldExistsQuery` here maybe, or perhaps the test needs revising (haven't looked). ```suggestion final Query docsWithValues = new FieldExistsQuery(getAmountField(field).getName()); ``` -- 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] remove deprecated (DocValues,Norms)FieldExistsQuery use [solr]
cpoerschke commented on code in PR #2632: URL: https://github.com/apache/solr/pull/2632#discussion_r1932717320 ## solr/core/src/java/org/apache/solr/schema/CurrencyFieldType.java: ## @@ -387,7 +385,8 @@ private Query getRangeQueryInternal( (p1 != null) ? p1.getCurrencyCode() : (p2 != null) ? p2.getCurrencyCode() : defaultCurrency; // ValueSourceRangeFilter doesn't check exists(), so we have to -final Query docsWithValues = new DocValuesFieldExistsQuery(getAmountField(field).getName()); +SchemaField amountField = getAmountField(field); Review Comment: minor ```suggestion final SchemaField amountField = getAmountField(field); ``` -- 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-17447 : Support to early terminate a search based on maxHits per collector. [solr]
sijuv commented on code in PR #2960:
URL: https://github.com/apache/solr/pull/2960#discussion_r1932759503
##
solr/core/src/java/org/apache/solr/response/SolrQueryResponse.java:
##
@@ -68,6 +68,7 @@ public class SolrQueryResponse {
public static final String RESPONSE_HEADER_PARTIAL_RESULTS_DETAILS_KEY =
"partialResultsDetails";
public static final String RESPONSE_HEADER_SEGMENT_TERMINATED_EARLY_KEY =
"segmentTerminatedEarly";
+ public static final String RESPONSE_HEADER_TERMINATED_EARLY_KEY =
"terminatedEarly";
Review Comment:
updated.
--
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-17447 : Support to early terminate a search based on maxHits per collector. [solr]
sijuv commented on code in PR #2960:
URL: https://github.com/apache/solr/pull/2960#discussion_r1932760465
##
solr/core/src/java/org/apache/solr/search/EarlyTerminatingCollector.java:
##
@@ -29,11 +30,15 @@
*/
public class EarlyTerminatingCollector extends FilterCollector {
+ private final int chunkSize = 100; // Check across threads only at a chunk
size
+
private final int maxDocsToCollect;
private int numCollected = 0;
private int prevReaderCumulativeSize = 0;
private int currentReaderSize = 0;
+ private final AtomicInteger pendingDocsToCollect;
Review Comment:
Chunking we will still need. LongAdder add does not return the current count
and doing increment and then get on every document I don't think will be
optimal.
##
solr/core/src/java/org/apache/solr/search/MultiThreadedSearcher.java:
##
@@ -255,7 +265,11 @@ public Object reduce(Collection collectors) throws
IOException {
for (Iterator var4 = collectors.iterator();
var4.hasNext();
maxScore = Math.max(maxScore, collector.getMaxScore())) {
-collector = (MaxScoreCollector) var4.next();
+Collector next = (Collector) var4.next();
Review Comment:
Done
--
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-17447 : Support to early terminate a search based on maxHits per collector. [solr]
sijuv commented on code in PR #2960:
URL: https://github.com/apache/solr/pull/2960#discussion_r1932762106
##
solr/core/src/java/org/apache/solr/search/QueryCommand.java:
##
@@ -194,7 +195,7 @@ public QueryCommand setNeedDocSet(boolean needDocSet) {
}
public boolean getTerminateEarly() {
-return (flags & SolrIndexSearcher.TERMINATE_EARLY) != 0;
+return (flags & SolrIndexSearcher.TERMINATE_EARLY) != 0 || maxHits <
Integer.MAX_VALUE;
Review Comment:
done.
--
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-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-2619918214 > A test is needed. added tests. -- 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-17447 : Support to early terminate a search based on maxHits per collector. [solr]
sijuv commented on code in PR #2960:
URL: https://github.com/apache/solr/pull/2960#discussion_r1932766821
##
solr/core/src/java/org/apache/solr/search/QueryResult.java:
##
@@ -22,6 +22,7 @@ public class QueryResult {
// Object for back compatibility so that we render true not "true" in json
private Object partialResults;
private Boolean segmentTerminatedEarly;
Review Comment:
I think we need to distinguish the 2 because the cause for them is different
. segmentTerminateEarly could occur because of the searcher not proceeding on a
sorted segment because the remaning docs are of lower _score_. The
terminateEarly is purely due to the searcher running past the provided number
of maxHits. As a user if I see terminateEarly then I know I might need to
increase the maxHits parameter.
##
solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java:
##
@@ -338,6 +339,11 @@ private Collector buildAndRunCollectorChain(
if (cmd.isQueryCancellable()) {
core.getCancellableQueryTracker().removeCancellableQuery(cmd.getQueryID());
}
+ if (collector instanceof final EarlyTerminatingCollector
earlyTerminatingCollector) {
Review Comment:
done.
--
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-17447 : Support to early terminate a search based on maxHits per collector. [solr]
sijuv commented on code in PR #2960: URL: https://github.com/apache/solr/pull/2960#discussion_r1932767430 ## solr/solr-ref-guide/modules/query-guide/pages/common-query-parameters.adoc: ## @@ -399,6 +399,22 @@ For example, setting `cpuAllowed=500` gives a limit of at most 500 ms of CPU tim All other considerations regarding partial results listed for the `timeAllowed` parameter apply here, too. + +== maxHits Parameter + +[%autowidth,frame=none] +|=== +|Optional |Default: `false` +|=== + +This parameter specifies the max number of hits a searcher will iterate through before early terminating the search. +The count is per shard and across all threads involved in case of multi-threaded search. This parameter works +in conjunction with other parameters that could early terminate a search, ex: _timeAllowed_ etc. In case the search +was early terminated due to it exceeding maxHits a _terminatedEarly_ header in the response will be set along with +_partialResults_ to indicate the same +Note : the hits counted will need not be exactly equal to the maxHits provided, however it will be within range of this value. Review Comment: updated documentation. -- 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-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-2619919386 @dsmiley @HoustonPutman updated, pls take a look when you get a chance. -- 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-17504) CoreContainer calls UpdateHandler.commit
[ https://issues.apache.org/jira/browse/SOLR-17504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921867#comment-17921867 ] ASF subversion and git services commented on SOLR-17504: Commit 3be16e25517f46b9a4cdfd35bd0036d93d728743 in solr's branch refs/heads/main from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=3be16e25517 ] SOLR-17504: Ensure DirectUpdateHandlerWithUpdateLogTest always uses updateLog > CoreContainer calls UpdateHandler.commit > > > Key: SOLR-17504 > URL: https://issues.apache.org/jira/browse/SOLR-17504 > Project: Solr > Issue Type: Improvement >Reporter: Bruno Roustant >Assignee: Bruno Roustant >Priority: Major > Labels: pull-request-available > Fix For: 9.8 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > ... and DirectUpdateHandler2.closeWriter supports commit metadata. > This proposal is about unifying calls to UpdateHandler.commit. > CoreContainer.reload may call directly IndexWriter.commit if the core to > reload is readonly (property of the Collection). This is an issue because it > bypasses some logic in UpdateHandler.commit. In addition, the current code > commits without taking the commit lock. > DirectUpdateHandler2.closeWriter may commit if the update log is not empty > (not committed yet). But it does not call DirectUpdateHandler2.commit(), it > copies commit() code instead for some reasons (comments in the code mention > test failures). The proposal is to add the same call to > DirectUpdateHandler2.shouldCommit() as in the commit() method, otherwise > commit metadata are lost. In addition shouldCommit() can be extended > correctly, for example in the solr-sandbox encryption module which needs to > intercept calls to shouldCommit(). -- 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-17342) Comply with ASF website policy - external resources
[
https://issues.apache.org/jira/browse/SOLR-17342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921865#comment-17921865
]
Jan Høydahl commented on SOLR-17342:
The deadline is March 1st, so no rush. But we could replace widgets with simple
links, perhaps with a static png image or something.
> Comply with ASF website policy - external resources
> ---
>
> Key: SOLR-17342
> URL: https://issues.apache.org/jira/browse/SOLR-17342
> Project: Solr
> Issue Type: New Feature
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Labels: pull-request-available
> Attachments: Skjermbilde 2025-01-23 kl. 11.08.23.png, Skjermbilde
> 2025-01-28 kl. 14.26.58.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The only website policy solr violates is linking to external resources:
> [https://whimsy.apache.org/site/project/solr]
> We should copy resources to our template instead of linking. The ones we link
> to in _css.html are:
>
> {code:java}
> rel='stylesheet' type='text/css'>
> href="//maxcdn.bootstrapcdn.com/font-awesome/4.1.0/css/font-awesome.min.css"
> rel="stylesheet">
> href="//cdn.jsdelivr.net/jquery.slick/1.3.7/slick.css"/> {code}
> Note that the links are in multiple files.
>
--
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] Fix TestReplicationHandler [solr]
HoustonPutman commented on code in PR #3142:
URL: https://github.com/apache/solr/pull/3142#discussion_r1932899214
##
solr/core/src/test/org/apache/solr/handler/TestReplicationHandler.java:
##
@@ -1037,8 +1036,7 @@ private int indexDirCount(String ddir) {
@Override
public boolean accept(File dir, String name) {
File f = new File(dir, name);
-return f.isDirectory()
-&&
!SolrSnapshotMetaDataManager.SNAPSHOT_METADATA_DIR.equals(name);
+return f.isDirectory() && !name.startsWith("snapshot");
Review Comment:
agreed, it's just in the error output that the snapshot is there. I know no
magic 😅
--
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-17504) CoreContainer calls UpdateHandler.commit
[ https://issues.apache.org/jira/browse/SOLR-17504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921869#comment-17921869 ] ASF subversion and git services commented on SOLR-17504: Commit d48869a77d626e4546de6e8fe9c7f4251fff5ea8 in solr's branch refs/heads/branch_9x from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=d48869a77d6 ] SOLR-17504: Ensure DirectUpdateHandlerWithUpdateLogTest always uses updateLog (cherry picked from commit 3be16e25517f46b9a4cdfd35bd0036d93d728743) > CoreContainer calls UpdateHandler.commit > > > Key: SOLR-17504 > URL: https://issues.apache.org/jira/browse/SOLR-17504 > Project: Solr > Issue Type: Improvement >Reporter: Bruno Roustant >Assignee: Bruno Roustant >Priority: Major > Labels: pull-request-available > Fix For: 9.8 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > ... and DirectUpdateHandler2.closeWriter supports commit metadata. > This proposal is about unifying calls to UpdateHandler.commit. > CoreContainer.reload may call directly IndexWriter.commit if the core to > reload is readonly (property of the Collection). This is an issue because it > bypasses some logic in UpdateHandler.commit. In addition, the current code > commits without taking the commit lock. > DirectUpdateHandler2.closeWriter may commit if the update log is not empty > (not committed yet). But it does not call DirectUpdateHandler2.commit(), it > copies commit() code instead for some reasons (comments in the code mention > test failures). The proposal is to add the same call to > DirectUpdateHandler2.shouldCommit() as in the commit() method, otherwise > commit metadata are lost. In addition shouldCommit() can be extended > correctly, for example in the solr-sandbox encryption module which needs to > intercept calls to shouldCommit(). -- 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] Fix TestReplicationHandler [solr]
HoustonPutman commented on PR #3142: URL: https://github.com/apache/solr/pull/3142#issuecomment-2620119361 > Thanks @HoustonPutman for looking at these, and sorry I didn't catch them, as I think I reviewed both of those PR's. Is there some more unit testing that we need that would have prevented these regressions? We should have another crave job that runs the nightly tests. I looked into it, but I don't know where our crave config lives, so I don't know how to enable that. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-17504) CoreContainer calls UpdateHandler.commit
[ https://issues.apache.org/jira/browse/SOLR-17504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921871#comment-17921871 ] ASF subversion and git services commented on SOLR-17504: Commit 3d740719d295cfa2efa65669d5b645005db3d998 in solr's branch refs/heads/branch_9_8 from Houston Putman [ https://gitbox.apache.org/repos/asf?p=solr.git;h=3d740719d29 ] SOLR-17504: Ensure DirectUpdateHandlerWithUpdateLogTest always uses updateLog (cherry picked from commit 3be16e25517f46b9a4cdfd35bd0036d93d728743) > CoreContainer calls UpdateHandler.commit > > > Key: SOLR-17504 > URL: https://issues.apache.org/jira/browse/SOLR-17504 > Project: Solr > Issue Type: Improvement >Reporter: Bruno Roustant >Assignee: Bruno Roustant >Priority: Major > Labels: pull-request-available > Fix For: 9.8 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > ... and DirectUpdateHandler2.closeWriter supports commit metadata. > This proposal is about unifying calls to UpdateHandler.commit. > CoreContainer.reload may call directly IndexWriter.commit if the core to > reload is readonly (property of the Collection). This is an issue because it > bypasses some logic in UpdateHandler.commit. In addition, the current code > commits without taking the commit lock. > DirectUpdateHandler2.closeWriter may commit if the update log is not empty > (not committed yet). But it does not call DirectUpdateHandler2.commit(), it > copies commit() code instead for some reasons (comments in the code mention > test failures). The proposal is to add the same call to > DirectUpdateHandler2.shouldCommit() as in the commit() method, otherwise > commit metadata are lost. In addition shouldCommit() can be extended > correctly, for example in the solr-sandbox encryption module which needs to > intercept calls to shouldCommit(). -- 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-17334) Minor bugs in Solr dedicated coordinator mode
[
https://issues.apache.org/jira/browse/SOLR-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921874#comment-17921874
]
Anshum Gupta commented on SOLR-17334:
-
is this good to be closed?
> Minor bugs in Solr dedicated coordinator mode
> -
>
> Key: SOLR-17334
> URL: https://issues.apache.org/jira/browse/SOLR-17334
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 9.6
>Reporter: Torsten Bøgh Köster
>Assignee: Noble Paul
>Priority: Major
> Labels: pull-request-available
> Fix For: 9.8
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> We recently put dedicated Solr coordinator nodes into production and stumbled
> upon some minor bugs/improvements:
> - The Solr root resource cannot be requested on a coordinator node
> - Coordinator requests are enabled for the {{/select}} handler only
> - From outside proxied and coordinator requests cannot be distinguished
> h3. Solr root resource
> We adopted a general fix from the {{HttpSolrCall}} to check whether the given
> {{collectionName}} is {{{}null{}}}. This fixes requesting the root resource
> (and maybe other similar requests)
> h3. {{/select}} handler only
> Coordinator requests are limited to the {{/select}} handler. In our
> environment we make heavy usage of pre-configured Solr handlers. We could not
> find any reason to limit coordinator calls to the {{/select}} handler and
> removed the limitation.
> h3. Coordinator requests cannot be identified by Solr response
> With any Solr response you cannot distinguish coordinator from proxied (or
> regular) requests. While this is great for consistency it makes testing extra
> hard. We added an extra Solr header field with the coordinator node name
> called {{requestCoordinatorNode}} when debug is enabled. This eases testing
> and debugging a lot.
>
> A Pull Request is in the making!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Updated] (SOLR-17334) Minor bugs in Solr dedicated coordinator mode
[
https://issues.apache.org/jira/browse/SOLR-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshum Gupta updated SOLR-17334:
Fix Version/s: (was: 9.8)
> Minor bugs in Solr dedicated coordinator mode
> -
>
> Key: SOLR-17334
> URL: https://issues.apache.org/jira/browse/SOLR-17334
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
>Affects Versions: 9.6
>Reporter: Torsten Bøgh Köster
>Assignee: Noble Paul
>Priority: Major
> Labels: pull-request-available
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> We recently put dedicated Solr coordinator nodes into production and stumbled
> upon some minor bugs/improvements:
> - The Solr root resource cannot be requested on a coordinator node
> - Coordinator requests are enabled for the {{/select}} handler only
> - From outside proxied and coordinator requests cannot be distinguished
> h3. Solr root resource
> We adopted a general fix from the {{HttpSolrCall}} to check whether the given
> {{collectionName}} is {{{}null{}}}. This fixes requesting the root resource
> (and maybe other similar requests)
> h3. {{/select}} handler only
> Coordinator requests are limited to the {{/select}} handler. In our
> environment we make heavy usage of pre-configured Solr handlers. We could not
> find any reason to limit coordinator calls to the {{/select}} handler and
> removed the limitation.
> h3. Coordinator requests cannot be identified by Solr response
> With any Solr response you cannot distinguish coordinator from proxied (or
> regular) requests. While this is great for consistency it makes testing extra
> hard. We added an extra Solr header field with the coordinator node name
> called {{requestCoordinatorNode}} when debug is enabled. This eases testing
> and debugging a lot.
>
> A Pull Request is in the making!
--
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] [Resolved] (SOLR-17590) Complete Major changes and Upgrade Notes in RefGuide for 9.8.0
[ https://issues.apache.org/jira/browse/SOLR-17590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta resolved SOLR-17590. - Resolution: Fixed > Complete Major changes and Upgrade Notes in RefGuide for 9.8.0 > -- > > Key: SOLR-17590 > URL: https://issues.apache.org/jira/browse/SOLR-17590 > Project: Solr > Issue Type: Task > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Anshum Gupta >Assignee: Anshum Gupta >Priority: Blocker > Fix For: 9.8 > > > Blocker to make sure a 9.8.0 release is not announced before the reference > guide is complete. -- 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-17379) ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
[
https://issues.apache.org/jira/browse/SOLR-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17921977#comment-17921977
]
Houston Putman commented on SOLR-17379:
---
So after far too much debugging, I figured out that it's an issue with the
security manager. The {{TestSecurityManager}} provided by Lucene swallows up
the error for some reason, but going back to the default Security Manager
prints out a TON of:
{{java.security.policy: error adding Permission, java.net.URLPermission:}}
{{ java.util.ServiceConfigurationError: Locale provider adapter
"CLDR"cannot be instantiated.}}
While this doesn't matter for most tests, the French test relies on having more
than just English, so it fails. When we remove the security manager this will
start succeeding.
> ParsingFieldUpdateProcessorsTest failures using CLDR locale provider
>
>
> Key: SOLR-17379
> URL: https://issues.apache.org/jira/browse/SOLR-17379
> Project: Solr
> Issue Type: Test
>Reporter: Chris M. Hostetter
>Priority: Major
> Attachments: SOLR-17379.test-1.patch, SOLR-17379.test.patch
>
>
> Background: https://lists.apache.org/thread/o7xwz8df6j0bx7w2m3w8ptrp4r7q957n
> Test failures from {{ParsingFieldUpdateProcessorsTest.testAKSTZone}} and
> {{ParsingFieldUpdateProcessorsTest.testParseFrenchDate}} are seemingly
> guaranteed on JDK23, due to the removal of the {{COMPAT}} local provider
> option.
> On (some) earlier JDKs, these failures can be reproduced using...
> {noformat}
> ./gradlew test --tests ParsingFieldUpdateProcessorsTest
> -Ptests.jvmargs="-Djava.locale.providers=CLDR -XX:TieredStopAtLevel=1
> -XX:+UseParallelGC -XX:ActiveProcessorCount=1 -XX:ReservedCodeCacheSize=120m"
> {noformat}
> ...to force the use off {{CLDR}} and exclude the use of {{COMPAT}}
--
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-17623: Simple ordered map should implement map [solr]
cpoerschke commented on code in PR #3048:
URL: https://github.com/apache/solr/pull/3048#discussion_r1932629861
##
solr/solrj/build.gradle:
##
@@ -81,7 +81,7 @@ dependencies {
testRuntimeOnly(libs.eclipse.jetty.alpnjavaserver, {
exclude group: "org.eclipse.jetty.alpn", module: "alpn-api"
})
- testImplementation(libs.mockito.core, {
+ testImplementation(libs.mockito.core, {hb
Review Comment:
```suggestion
testImplementation(libs.mockito.core, {
```
--
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-17342) Comply with ASF website policy - external resources
[
https://issues.apache.org/jira/browse/SOLR-17342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Høydahl updated SOLR-17342:
---
Attachment: Skjermbilde 2025-01-28 kl. 14.26.58.png
> Comply with ASF website policy - external resources
> ---
>
> Key: SOLR-17342
> URL: https://issues.apache.org/jira/browse/SOLR-17342
> Project: Solr
> Issue Type: New Feature
> Components: website
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>Priority: Major
> Labels: pull-request-available
> Attachments: Skjermbilde 2025-01-23 kl. 11.08.23.png, Skjermbilde
> 2025-01-28 kl. 14.26.58.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The only website policy solr violates is linking to external resources:
> [https://whimsy.apache.org/site/project/solr]
> We should copy resources to our template instead of linking. The ones we link
> to in _css.html are:
>
> {code:java}
> rel='stylesheet' type='text/css'>
> href="//maxcdn.bootstrapcdn.com/font-awesome/4.1.0/css/font-awesome.min.css"
> rel="stylesheet">
> href="//cdn.jsdelivr.net/jquery.slick/1.3.7/slick.css"/> {code}
> Note that the links are in multiple files.
>
--
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] remove deprecated (DocValues,Norms)FieldExistsQuery use [solr]
HoustonPutman commented on PR #2632: URL: https://github.com/apache/solr/pull/2632#issuecomment-2619714256 Ok I've undone the pointField stuff, as the only clean way is to throw an error to users. So let's do https://issues.apache.org/jira/browse/SOLR-14199 completely separately. -- 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] Jetty12 + EE10 [solr]
dsmiley commented on code in PR #2876:
URL: https://github.com/apache/solr/pull/2876#discussion_r1932792887
##
solr/test-framework/src/java/org/apache/solr/embedded/JettySolrRunner.java:
##
@@ -414,16 +415,16 @@ public void contextInitialized(ServletContextEvent event)
{
// Default servlet as a fall-through
root.addServlet(Servlet404.class, "/");
- chain = root;
+ chain.setHandler(root);
Review Comment:
it's be clearer to do this at the front of this block.
--
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 TestReplicationHandler [solr]
HoustonPutman opened a new pull request, #3142:
URL: https://github.com/apache/solr/pull/3142
This actually stems from two commits on the same day, kind of eerie.
### [SOLR-17306](https://issues.apache.org/jira/browse/SOLR-17306)
This uncommented out:
```java
System.setProperty("solr.directoryFactory", "solr.StandardDirectoryFactory");
```
Apparently when using the StandardDirectoryFactory, we see core snapshot
directories when we don't see them using the default DirectoryFactory. The code
already accounted for snapshot metadata, but not snapshots themselves. I
updated the check to ignore any snapshot directory when counting index
directories. @dsmiley, you wrote the snapshot metadata filtering, so can you
check this for me?
### [SOLR-17548](https://issues.apache.org/jira/browse/SOLR-17548)
In `ReplicationTestHelper`, this changed
```java
FileUtils.copyFile(
new File(SolrTestCaseJ4.TEST_HOME(), "solr.xml"),
new File(instance.getHomeDir(), "solr.xml"));
```
to
```java
Files.copy(
Path.of(SolrTestCaseJ4.TEST_HOME(), "solr.xml"),
Path.of(instance.getHomeDir(), "solr.xml"));
```
However, this forgot to allow for overwrites, as was done in other cases in
this PR. Probably because nightly tests are usually forgotten.
--
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 TestReplicationHandler [solr]
epugh commented on PR #3142: URL: https://github.com/apache/solr/pull/3142#issuecomment-2620046961 @mlbiscoc I should have reminded/and or run the nightly tests when I was reviewing the path stuff.. Let's remember to do that as we continue! -- 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 TestReplicationHandler [solr]
epugh commented on PR #3142: URL: https://github.com/apache/solr/pull/3142#issuecomment-2620051699 Thanks @HoustonPutman for looking at these, and sorry I didn't catch them, as I think I reviewed both of those PR's. Is there some more unit testing that we need that would have prevented these regressions? -- 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 TestReplicationHandler [solr]
epugh commented on code in PR #3142:
URL: https://github.com/apache/solr/pull/3142#discussion_r1932855830
##
solr/core/src/test/org/apache/solr/handler/TestReplicationHandler.java:
##
@@ -1037,8 +1036,7 @@ private int indexDirCount(String ddir) {
@Override
public boolean accept(File dir, String name) {
File f = new File(dir, name);
-return f.isDirectory()
-&&
!SolrSnapshotMetaDataManager.SNAPSHOT_METADATA_DIR.equals(name);
+return f.isDirectory() && !name.startsWith("snapshot");
Review Comment:
this seems so "magical" that you have to know about a "snapshot".
--
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-17447 : Support to early terminate a search based on maxHits per collector. [solr]
dsmiley commented on code in PR #2960:
URL: https://github.com/apache/solr/pull/2960#discussion_r1933299568
##
solr/core/src/java/org/apache/solr/search/QueryResult.java:
##
@@ -22,6 +22,7 @@ public class QueryResult {
// Object for back compatibility so that we render true not "true" in json
private Object partialResults;
private Boolean segmentTerminatedEarly;
Review Comment:
Okay; so the cause is interesting for diagnostic / observability purposes
but semantically, the search has "terminated early" (for whatever reason).
--
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 TestReplicationHandler [solr]
dsmiley commented on PR #3142: URL: https://github.com/apache/solr/pull/3142#issuecomment-2620779247 I raised the topic on the dev list but FYI I'm our resident Crave expert. -- 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-17623: Simple ordered map should implement map [solr]
dsmiley commented on code in PR #3048:
URL: https://github.com/apache/solr/pull/3048#discussion_r1933308834
##
solr/solrj/build.gradle:
##
@@ -48,7 +48,6 @@ dependencies {
})
implementation libs.apache.httpcomponents.httpclient
implementation libs.apache.httpcomponents.httpcore
- implementation libs.apache.commons.lang3
Review Comment:
weird; what's that doing in this PR?
##
solr/solrj/src/java/org/apache/solr/common/util/SimpleOrderedMap.java:
##
@@ -146,43 +126,21 @@ public T remove(final Object key) {
return super.remove((String) key);
}
- /**
- * Copies all of the mappings from the specified map to this map. These
mappings will replace any
- * mappings that this map had for any of the keys currently in the specified
map.
- *
- * @param m mappings to be stored in this map
- * @throws NullPointerException if the specified map is null
- */
@Override
public void putAll(final Map m) {
m.forEach(this::put);
Review Comment:
if you look at NamedList's shallow Map putAll impl, there's a faster
implementation if the map is empty at the start. We could incorporate that
here with a simple check that calls `this::add`
--
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] [Resolved] (SOLR-17519) CloudSolrClient with HTTP ClusterState can forget live nodes and then fail
[
https://issues.apache.org/jira/browse/SOLR-17519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-17519.
-
Fix Version/s: 9.9
Resolution: Fixed
Merged and done. Thanks for your contribution here Matthew!
> CloudSolrClient with HTTP ClusterState can forget live nodes and then fail
> --
>
> Key: SOLR-17519
> URL: https://issues.apache.org/jira/browse/SOLR-17519
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud, SolrJ
>Reporter: David Smiley
>Priority: Major
> Labels: newdev, pull-request-available
> Fix For: 9.9
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> When using CloudSolrClient with HTTP URLs to Solr for the cluster state:
> If all live nodes disappear temporarily (hard cluster restart?), the client
> can permanently fail to talk to the cluster, and thus would need to be
> restarted to recover.
> Credit [~ilan] on the dev list:
> {quote}The current implementation removes non live nodes from the set of
> nodes to connect to. Getting the live nodes requires connecting to a specific
> node in the cluster that is therefore live when that happens. Worst case, if
> there is a single node up in the cluster, the client ends with a single node
> in its connection candidates list. For the issue to manifest, that Solr node
> then has to go down. Subsequently, even if other nodes are up, the client
> only has the address of a down node and can't connect.
> The fix is not a big deal. Nodes initially passed as configuration to the
> client should never be removed from the set of candidate nodes to connect to,
> even if they are not live. Other live nodes could be added to that set (and
> removed from it if we so desire when they are no longer live) to increase
> resiliency in case the cluster does have live nodes but all initially
> configured nodes are not live. The design issue is treating the configured
> set of nodes to connect to and the set of live nodes as one thing.
> {quote}
> See org.apache.solr.client.solrj.impl.BaseHttpClusterStateProvider
--
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: [I] Use custom name for the ServiceAccount of Zookeeper operator [solr-operator]
saurabh-adhikari commented on issue #750: URL: https://github.com/apache/solr-operator/issues/750#issuecomment-2620881139 By default, the Zookeeper Operator creates a ServiceAccount named zookeeper-operator when installed via the Solr Operator dependency chart. This behavior can be modified by overriding the configurable parameters in [solr-operator](https://github.com/apache/solr-operator/blob/0ffddb6a4be25ffb3fdad6cb3ffe759d89c5fcf2/helm/solr-operator/README.md#running-the-solr-operator) and [zookeeper-operator](https://github.com/pravega/zookeeper-operator/tree/master/charts/zookeeper-operator#configuration) through values.yaml. To create a ServiceAccount with a custom name in the default namespace (where another Solr Operator exists), following configuration can be applied: ```yaml solr-operator: serviceAccount: create: false name: zookeeper-operator-custom zookeeper-operator: serviceAccount: create: true name: zookeeper-operator-custom ``` -- 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
