Re: [I] Replica recovery fails after using Solr Encryption Plugin in multi-sharded Solr collection [solr-sandbox]

[via GitHub]

bruno-roustant commented on issue #114:
URL: https://github.com/apache/solr-sandbox/issues/114#issuecomment-2606927844

   Nice investigation @danielsason112.,this seems to be a good lead!
   
   It reminds me the file length complexity I had to solve when initially 
developing the EncryptionDirectory in Lucene, to be compatible with the 
compound file format and other Lucene file length checks.
   I'll look deeper at this file length issue to confirm.


-- 
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-16391: Convert create-core, core-status, /luke to JAX-RS [solr]

[via GitHub]

gerlowskija opened a new pull request, #3054:
URL: https://github.com/apache/solr/pull/3054

   https://issues.apache.org/jira/browse/SOLR-16391
   
   # Description
   
   Many v2 APIs remain on the legacy v2 API framework, including a number of 
APIs dealing with core CRUD and status-checking.
   
   # Solution
   
   This commit migrates four APIs: create-core, single-core-status, 
all-core-status, and the "luke" request handler over to the JAX-RS framework.  
This adds the APIs to our growing OpenAPI spec, and ensures that 
SolrRequest/SolrResponse implementations are generated for each.
   
   Since the v1 and v2 response formats are the same for each API converted in 
this PR, the response POJOs are also useful in existing tests for our v1 APIs, 
and this PR rolls out some of that usage to clear up needless casting and 
NamedList inspection.
   
   Lastly, this PR modifies some 'public'-visibility SolrJ methods that will 
need properly deprecated in an eventual 9x backport.  I've tried to flag those 
with a PR comment where I'm aware of the change.  Please point out any others 
I've missed. 
   
   # Tests
   
   TBD
   
   # 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, not available for 
branches on forks living under an organisation)
   - [x] I have developed this patch against the `main` branch.
   - [x] 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-16391: Convert create-core, core-status, /luke to JAX-RS [solr]

[via GitHub]

gerlowskija commented on PR #3054:
URL: https://github.com/apache/solr/pull/3054#issuecomment-2607074917

   Still TODO: expand response POJOs usage in tests where appropriate, 
ref-guide updates for APIs, flag methods-needing-deprecation with PR comments.


-- 
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] Remove unused 9.7.1 section in CHANGES.txt [solr]

[via GitHub]

janhoy opened a new pull request, #3055:
URL: https://github.com/apache/solr/pull/3055

   Unfortunately this also made it into the 9.8.0 release :( 


-- 
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-16391: Convert create-core, core-status, /luke to JAX-RS [solr]

[via GitHub]

epugh commented on PR #3054:
URL: https://github.com/apache/solr/pull/3054#issuecomment-2607239877

   As my 13 year old would say, [you are 
cookin](https://whitestationscroll.net/10380/opinion/are-you-cooked-or-cooking-a-brain-rot-guide/)!
   
   
   Out of curiosity, at this point, do you think we need to keep up the 
emphasis on back porting to 9x..If we smell 10 on the horizon, maybe we 
don't worry about backporting..


-- 
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-17631) Upgrade main to Lucene 10.x

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated SOLR-17631:
--
Labels: pull-request-available  (was: )

> Upgrade main to Lucene 10.x
> ---
>
> Key: SOLR-17631
> URL: https://issues.apache.org/jira/browse/SOLR-17631
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Now that we have 9.8 release of Solr based on Lucene 9.12, we should move to 
> main + Lucene 10. Towards that, I've started on a WIP branch. Opening this 
> issue to track the effort needed for that.



--
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-16391: Convert create-core, core-status, /luke to JAX-RS [solr]

[via GitHub]

epugh commented on code in PR #3054:
URL: https://github.com/apache/solr/pull/3054#discussion_r1925318212


##
solr/core/src/java/org/apache/solr/cli/CLIUtils.java:
##
@@ -321,16 +320,15 @@ public static boolean safeCheckCoreExists(String solrUrl, 
String coreName, Strin
   final int clamPeriodForStatusPollMs = 1000;
   Thread.sleep(clamPeriodForStatusPollMs);
 }
-NamedList existsCheckResult =
-CoreAdminRequest.getStatus(coreName, solrClient).getResponse();
-NamedList status = (NamedList) 
existsCheckResult.get("status");
-NamedList coreStatus = (NamedList) 
status.get(coreName);
-Map failureStatus =
-(Map) existsCheckResult.get("initFailures");
-String errorMsg = (String) failureStatus.get(coreName);
-final boolean hasName = coreStatus != null && coreStatus.get(NAME) != 
null;
-exists = hasName || errorMsg != null;
-wait = hasName && errorMsg == null && 
"true".equals(coreStatus.get("isLoading"));
+final var coreStatusReq = new CoresApi.GetCoreStatus(coreName);
+final var coreStatusRsp = 
coreStatusReq.process(solrClient).getParsed();
+final var coreStatusByName = coreStatusRsp.status;
+final var coreStatus = coreStatusByName.get(coreName);

Review Comment:
   these `var` are a lot more readable...



##
solr/core/src/java/org/apache/solr/cli/CLIUtils.java:
##
@@ -321,16 +320,15 @@ public static boolean safeCheckCoreExists(String solrUrl, 
String coreName, Strin
   final int clamPeriodForStatusPollMs = 1000;
   Thread.sleep(clamPeriodForStatusPollMs);
 }
-NamedList existsCheckResult =
-CoreAdminRequest.getStatus(coreName, solrClient).getResponse();
-NamedList status = (NamedList) 
existsCheckResult.get("status");
-NamedList coreStatus = (NamedList) 
status.get(coreName);
-Map failureStatus =
-(Map) existsCheckResult.get("initFailures");
-String errorMsg = (String) failureStatus.get(coreName);
-final boolean hasName = coreStatus != null && coreStatus.get(NAME) != 
null;
-exists = hasName || errorMsg != null;
-wait = hasName && errorMsg == null && 
"true".equals(coreStatus.get("isLoading"));
+final var coreStatusReq = new CoresApi.GetCoreStatus(coreName);
+final var coreStatusRsp = 
coreStatusReq.process(solrClient).getParsed();
+final var coreStatusByName = coreStatusRsp.status;
+final var coreStatus = coreStatusByName.get(coreName);
+final var failureStatus = coreStatusRsp.initFailures;
+final var initFailureForCore = failureStatus.get(coreName);
+final boolean hasName = coreStatus != null && coreStatus.name != null;
+exists = hasName || initFailureForCore != null;
+wait = hasName && initFailureForCore == null && 
"true".equals(coreStatus.isLoading);

Review Comment:
   boo that we are string comparing versus using a boolean...



##
solr/core/src/java/org/apache/solr/handler/admin/CoreAdminOperation.java:
##
@@ -92,32 +82,12 @@ public enum CoreAdminOperation implements CoreAdminOp {
   CREATE_OP(
   CREATE,
   it -> {
-assert TestInjection.injectRandomDelayInCoreCreation();

Review Comment:
   take it we don't need this in the future?   Or a pattern we don't want to 
continue?



##
solr/core/src/java/org/apache/solr/handler/admin/CoreAdminOperation.java:
##
@@ -327,70 +298,65 @@ public boolean isExpensive() {
* @return - a named list of key/value pairs from the core.
* @throws IOException - LukeRequestHandler can throw an I/O exception
*/
-  @SuppressWarnings({"unchecked", "rawtypes"})
-  public static NamedList getCoreStatus(
+  public static CoreStatusResponse.SingleCoreData getCoreStatus(
   CoreContainer cores, String cname, boolean isIndexInfoNeeded) throws 
IOException {
-NamedList info = new SimpleOrderedMap<>();
-
+final var info = new CoreStatusResponse.SingleCoreData();
 if (cores.isCoreLoading(cname)) {
-  info.add(NAME, cname);
-  info.add("isLoaded", "false");
-  info.add("isLoading", "true");
+  info.name = cname;
+  info.isLoaded = false;
+  info.isLoading = true;
 } else {
   if (!cores.isLoaded(cname)) { // Lazily-loaded core, fill in what we can.
 // It would be a real mistake to load the cores just to get the status
 CoreDescriptor desc = cores.getCoreDescriptor(cname);
 if (desc != null) {
-  info.add(NAME, desc.getName());
-  info.add("instanceDir", desc.getInstanceDir());
+  info.name = desc.getName();
+  info.instanceDir = desc.getInstanceDir().toString();
   // None of the following are guaranteed to be present in a 
not-yet-loaded core.
   String tmp = desc.getDataDir();
-  if (StrUtils.isNotBlank(tmp)) info.add("dataDir", tmp);
+ 

[jira] [Resolved] (SOLR-17500) Upgrade Lucene to 10.0.0 (on main)

[Ishan Chattopadhyaya (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-17500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ishan Chattopadhyaya resolved SOLR-17500.
-
Resolution: Duplicate

> Upgrade Lucene to 10.0.0 (on main)
> --
>
> Key: SOLR-17500
> URL: https://issues.apache.org/jira/browse/SOLR-17500
> Project: Solr
>  Issue Type: Task
>  Components: search
>Reporter: Jan Høydahl
>Priority: Blocker
> Fix For: main (10.0)
>
>
> Lucene has released v10.0.
> It requires Java 21, so depends on SOLR-17321. 
>  * [https://lucene.apache.org/core/10_0_0/changes/Changes.html]
>  * [https://github.com/apache/solr/blob/main/dev-docs/lucene-upgrade.md]
>  * 
> [https://lucene.apache.org/core/corenews.html#apache-lucenetm-1000-available] 



--
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-17631: Upgrade main to Lucene 10.x [solr]

[via GitHub]

chatman commented on PR #3053:
URL: https://github.com/apache/solr/pull/3053#issuecomment-2607539742

   I dealt with the removal of SortedSetDocValues.NO_MORE_ORDS [0] inaccurately 
in the PR. Will fix now.
   
   [0] - https://github.com/apache/lucene/pull/969


-- 
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-17631) Upgrade main to Lucene 10.x

[Ishan Chattopadhyaya (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17916088#comment-17916088
 ] 

Ishan Chattopadhyaya commented on SOLR-17631:
-

{quote}Please remember to search Kira before creating new issues.
{quote}
 
Sure, [~janhoy]. By the way,

{code:java}
 The Japanese name Kira means "glittery" or "shiny". It's a common name in 
Japan, used as both a given name and a family name. {code}


> Upgrade main to Lucene 10.x
> ---
>
> Key: SOLR-17631
> URL: https://issues.apache.org/jira/browse/SOLR-17631
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Now that we have 9.8 release of Solr based on Lucene 9.12, we should move to 
> main + Lucene 10. Towards that, I've started on a WIP branch. Opening this 
> issue to track the effort needed for that.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

[jira] [Created] (SOLR-17632) Text to Vector Update Request Processor

[Alessandro Benedetti (Jira)]

Alessandro Benedetti created SOLR-17632:
---

 Summary: Text to Vector Update Request Processor
 Key: SOLR-17632
 URL: https://issues.apache.org/jira/browse/SOLR-17632
 Project: Solr
  Issue Type: New Feature
  Components: UpdateRequestProcessors
Reporter: Alessandro Benedetti
Assignee: Alessandro Benedetti


Scope of this issue is to introduce support for automatic text vectorisation in 
Apache Solr, directly in a update request processor.
A LLM fine-tuned for sentence similarity will be accessed to embed the text.
Apache Solr will host the configuration parameters to access embedding services 
and the update request processor will use such services to directly encode the 
document field as a vector.




--
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-17619) Generate CHANGELOG.md (formerly CHANGES.txt) via logchange

[Jira]

[ 
https://issues.apache.org/jira/browse/SOLR-17619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17916082#comment-17916082
 ] 

Jan Høydahl commented on SOLR-17619:


The 9.8.0 release conains an erraneous 9.7.1 section in CHANGES.txt 
([https://github.com/apache/solr/pull/3055)]. It was not spotted by RM nor any 
reviewers.

I believe this is an incident that could have been caught more easily with 
logchange, since in that case there would be a "logchange/unreleased-9.7.1" 
folder on branch_9_8. You'd only expect to see one "unreleased-9.8.0" folder on 
that branch during release, so in the wizard's step to generate CHANGELOG.md, 
one could encourage RM to verify this.

> Generate CHANGELOG.md (formerly CHANGES.txt) via logchange
> --
>
> Key: SOLR-17619
> URL: https://issues.apache.org/jira/browse/SOLR-17619
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Reporter: David Smiley
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The [logchange|https://github.com/logchange/logchange] tool helps projects 
> maintain a log of changes. Each change (e.g. from a PR) will no longer edit a 
> CHANGES.txt file; instead it will include a _new_ YAML file in an appropriate 
> directory with others for the next Solr version.  The release process will 
> execute the tool, which will build a CHANGELOG.md file and will probably also 
> do something with the YAML files (remove?).
> Decide the most convenient way for us to run the tool for change authors.  
> Could a gradle task do it?  See [this 
> issue|https://github.com/logchange/logchange/issues/397] filed on the 
> logchange project.
> Outcome of this issue:
>  * a logchange tool configuration file -- logchange-config.yml
>  * Solr 10's CHANGES.txt entries converted to YAML.  (start this issue by 
> doing only a few before over-investing)
>  * a dev-docs page
>  ** for contributors/everyone: basic info explaining how each new change 
> should be recorded. Explain how to run the tool to generate the YAML file.  
> What field(s) matter the most; what should be ignored.  Link to further 
> details.
>  ** for release manager: how to produce CHANGELOG.md. Link to further 
> details.  Ultimately this will probably move to the release wizard in some 
> fashion.
> TBD: CHANGES.txt < 10 and CHANGELOG.md > 10 ?
> TBD: changes.html generation in the release process will be removed or will 
> change.



--
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-17602) Maintain final JAR dependencies in source control to track changes

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17916083#comment-17916083
 ] 

ASF subversion and git services commented on SOLR-17602:


Commit 7605593984238dfa4b4cd2b3e0faeeeb613d1366 in solr's branch 
refs/heads/main from Christos Malliaridis
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=76055939842 ]

SOLR-17602: Per-Module Dependency Locking (#2925)

* Introduce platform module

The platform module includes all dependencies from the
version catalog as constraints and is added to the root
modules as API for transitive inheritance of the constraints.

* Cleanup version catalog

* Fix dependency conflicts when errorprone enabled

* Add comment about platform module

* Enable per-module dependency lockfiles

Removes carrot-search dependencychecks plugin

* Update renovate config to use new task

* Update documentation

* Replace references to versions.props, versions.lock and writeLocks

* Add platform module as dependency to include constraints

* Update lockfiles

> Maintain final JAR dependencies in source control to track changes
> --
>
> Key: SOLR-17602
> URL: https://issues.apache.org/jira/browse/SOLR-17602
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Reporter: David Smiley
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When we make changes to Solr's dependencies (add/remove/change), we edit our 
> build files, and the code review process shows these changes to corresponding 
> build files.  However, what we all *really* want to know is the impact the 
> change has on the artifacts our users consume.  Almost nobody validates the 
> impact; we hope for the best and find out of problems long later.
> This issue tracks one artifact: Solr's final assembly (any of the zip, 
> tar.gz, or Docker). I propose committing to source control a machine 
> generated file listing of the dependencies  in a text file.  This file shall 
> be updated based on executing a gradle task TBD.  When gradle "check" is run, 
> it will henceforth ensure that this file hasn't been modified or doesn't 
> match the output of the script's generation (details TBD).



--
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-17602: Per-Module Dependency Locking [solr]

[via GitHub]

malliaridis merged PR #2925:
URL: https://github.com/apache/solr/pull/2925


-- 
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-17342) Comply with ASF website policy - external resources

[Jira]

[ 
https://issues.apache.org/jira/browse/SOLR-17342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17916085#comment-17916085
 ] 

Jan Høydahl commented on SOLR-17342:


This will soon be enforced by ASF so we should prioritize it. I wonder if there 
is any tooling that will automate fetching e.g. a font from cdn?

> 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
>
> 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-17631) Upgrade main to Lucene 10.x

[Jira]

[ 
https://issues.apache.org/jira/browse/SOLR-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17915976#comment-17915976
 ] 

Jan Høydahl commented on SOLR-17631:


Duplicates SOLR-17500. Please remember to search Kira before creating new 
issues.

> Upgrade main to Lucene 10.x
> ---
>
> Key: SOLR-17631
> URL: https://issues.apache.org/jira/browse/SOLR-17631
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Now that we have 9.8 release of Solr based on Lucene 9.12, we should move to 
> main + Lucene 10. Towards that, I've started on a WIP branch. Opening this 
> issue to track the effort needed for that.



--
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-17519: CloudSolrClient with HTTP ClusterState can forget live nodes and then fail [solr]

[via GitHub]

mlbiscoc commented on code in PR #2935:
URL: https://github.com/apache/solr/pull/2935#discussion_r1925380385


##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseHttpClusterStateProvider.java:
##
@@ -387,6 +398,19 @@ public String getPolicyNameByCollection(String coll) {
 + "ZkClientClusterStateProvider can be used for this."); // TODO
   }
 
+  private List setConfiguredNodes(List solrUrls) {

Review Comment:
   You're right bad naming. It's only used in the `init` so Instead I just 
removed the function as I don't think we need another utility method and it was 
somewhat small enough inlined the whole thing into the stream where it was 
called. Can move it into a private static utility if you prefer otherwise.



##
solr/solrj/src/test/org/apache/solr/client/solrj/impl/ClusterStateProviderTest.java:
##
@@ -204,8 +204,8 @@ public void 
testClusterStateProviderDownedInitialLiveNodes() throws Exception {
   var jettyNode1 = cluster.getJettySolrRunner(0);
   var jettyNode2 = cluster.getJettySolrRunner(1);
 
-  String nodeName1 = 
getNodeNameFromSolrUrl(jettyNode1.getBaseUrl().toString());
-  String nodeName2 = 
getNodeNameFromSolrUrl(jettyNode2.getBaseUrl().toString());
+  String nodeName1 = 
getNodeNameForBaseUrl(jettyNode1.getBaseUrl().toString());

Review Comment:
   Yeah it was deliberate. Was mostly to keep consistency between the names. 
`getNodeNameForBaseUrl` and `getBaseUrlForNodeName` but can switch it back if 
you prefer.



-- 
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-17629) SQL didn't always close internal resources if it encountered an exception

[David Smiley (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-17629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley resolved SOLR-17629.
-
Fix Version/s: 9.9
   Resolution: Fixed

> SQL didn't always close internal resources if it encountered an exception
> -
>
> Key: SOLR-17629
> URL: https://issues.apache.org/jira/browse/SOLR-17629
> Project: Solr
>  Issue Type: Bug
>  Components: Parallel SQL
>Reporter: David Smiley
>Assignee: David Smiley
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 9.9
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The SQLHandler internally creates a TupleStream and opens it.  If opening it 
> fails, the TupleStream isn't getting closed, as it should.
> What's kinda cool is that this bug was found via additional use of 
> ObjectReleaseTracker.



--
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-17602) Maintain final JAR dependencies in source control to track changes

[Christos Malliaridis (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17916177#comment-17916177
 ] 

Christos Malliaridis commented on SOLR-17602:
-

I would consider PR #2925 as pre-work that had to be done in order to proceed. 
It is indeed not satisfying the description of this issue, but provide now a 
good foundation to work on this. This is also the reason I haven't resolved the 
issue.

In order to address the issue, we need to understand how the lib directories 
are populated for each module. From what I believe, we use the {{runtimeLibs}} 
configurations, then, exclude all jars that belong to the project's modules and 
also all jars that are included in the {{solrPlatformLibs}} (which are all jars 
from {{{}core{}}}, {{{}solrj{}}}, {{{}api{}}}, {{solrj-zookeeper}} and a few 
other modules I believe).

This logic is coded in {{{}:solr:packaging{}}}. Now, what I am not sure is, 
would it be sufficient to find a way to list in the generated txt file (that is 
probably per module?) the jars that are included in each module from the 
{{assemble}} step?

> Maintain final JAR dependencies in source control to track changes
> --
>
> Key: SOLR-17602
> URL: https://issues.apache.org/jira/browse/SOLR-17602
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Reporter: David Smiley
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When we make changes to Solr's dependencies (add/remove/change), we edit our 
> build files, and the code review process shows these changes to corresponding 
> build files.  However, what we all *really* want to know is the impact the 
> change has on the artifacts our users consume.  Almost nobody validates the 
> impact; we hope for the best and find out of problems long later.
> This issue tracks one artifact: Solr's final assembly (any of the zip, 
> tar.gz, or Docker). I propose committing to source control a machine 
> generated file listing of the dependencies  in a text file.  This file shall 
> be updated based on executing a gradle task TBD.  When gradle "check" is run, 
> it will henceforth ensure that this file hasn't been modified or doesn't 
> match the output of the script's generation (details TBD).



--
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-17631: Upgrade main to Lucene 10.x [solr]

[via GitHub]

chatman commented on PR #3053:
URL: https://github.com/apache/solr/pull/3053#issuecomment-2607786041

   Now, here's the list of failing tests:
   
   ```TestRandomDVFaceting
   TestReversedWildcardFilterFactory
   TestGroupingSearch
   BasicFunctionalityTest
   TestDistributedGrouping
   TestDistributedSearch
   BasicDistributedZk2Test
   TestSegmentSorting
   DebugComponentTest
   DistributedFacetPivotLargeTest
   SOLR749Test
   TestIntervalFaceting
   PreAnalyzedFieldTest
   TestCloudJSONFacetJoinDomain
   TestComplexPhraseLeadingWildcard
   TestMissingGroups
   QueryElevationComponentTest
   TestFieldCacheSortRandom
   TestJsonFacetRefinement
   SimpleFacetsTest
   LargeFieldTest
   TestUninvertingReader
   TestQueryLimits
   TestFiltering
   TestTermsQParserPlugin
   TestCloudJSONFacetSKGEquiv
   PreAnalyzedUpdateProcessorTest
   ```


-- 
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] chore(deps): update dependency com.google.re2j:re2j to v1.8 - autoclosed [solr]

[via GitHub]

solrbot closed pull request #2986: chore(deps): update dependency 
com.google.re2j:re2j to v1.8 - autoclosed
URL: https://github.com/apache/solr/pull/2986


-- 
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-17342 Avoid loading from remote CDN [solr-site]

[via GitHub]

janhoy commented on PR #136:
URL: https://github.com/apache/solr-site/pull/136#issuecomment-2608096529

   > Didn't know about `#}` as a comment pattern. Thanks for this chore.
   
   I did not either, so I changed it to `

[jira] [Commented] (SOLR-17602) Maintain final JAR dependencies in source control to track changes

[David Smiley (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17916157#comment-17916157
 ] 

David Smiley commented on SOLR-17602:
-

That merged PR #2925 is related but doesn't appear to satisfy what the 
description of this issue asks for.  If it does but in a different way, okay, 
but then please help me understand.  Ultimately the point is to easily 
recognize what JARs we ship (in the .zip or .tar or Docker; any)  and when do 
those change in a PR.  I'm not aware of a 1:1 relationship with any Gradle 
"configuration" and that answer due to non-trivial packaging.

> Maintain final JAR dependencies in source control to track changes
> --
>
> Key: SOLR-17602
> URL: https://issues.apache.org/jira/browse/SOLR-17602
> Project: Solr
>  Issue Type: Task
>  Components: Build
>Reporter: David Smiley
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When we make changes to Solr's dependencies (add/remove/change), we edit our 
> build files, and the code review process shows these changes to corresponding 
> build files.  However, what we all *really* want to know is the impact the 
> change has on the artifacts our users consume.  Almost nobody validates the 
> impact; we hope for the best and find out of problems long later.
> This issue tracks one artifact: Solr's final assembly (any of the zip, 
> tar.gz, or Docker). I propose committing to source control a machine 
> generated file listing of the dependencies  in a text file.  This file shall 
> be updated based on executing a gradle task TBD.  When gradle "check" is run, 
> it will henceforth ensure that this file hasn't been modified or doesn't 
> match the output of the script's generation (details TBD).



--
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] chore(deps): update fasterxml to v2.18.2 [solr]

[via GitHub]

malliaridis merged PR #2950:
URL: https://github.com/apache/solr/pull/2950


-- 
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

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/SOLR-17342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated SOLR-17342:
--
Labels: pull-request-available  (was: )

> 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
>  Time Spent: 10m
>  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-17519: CloudSolrClient with HTTP ClusterState can forget live nodes and then fail [solr]

[via GitHub]

dsmiley commented on code in PR #2935:
URL: https://github.com/apache/solr/pull/2935#discussion_r1925844451


##
solr/CHANGES.txt:
##
@@ -176,6 +176,10 @@ Bug Fixes
 * SOLR-17629: If SQLHandler failed to open the underlying stream (e.g. Solr 
returns an error; could be user/syntax problem),
   it needs to close the stream to cleanup resources but wasn't. (David Smiley)
 
+* SOLR-17519: SolrJ fix to CloudSolrClient and HTTP ClusterState where it can 
fail to request cluster state
+  if its current live nodes list is stale. HTTP ClusterState now retains the 
initial configured list of passed URLs as backup

Review Comment:
   I don't think Solr users know about "HTTP ClusterState"; it's not likely in 
their vocabulary.  On the other hand, wording like "SolrJ CloudSolrClient 
configured with Solr URLs" is likely to be understood.



##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseHttpClusterStateProvider.java:
##
@@ -216,38 +236,42 @@ private SimpleOrderedMap submitClusterStateRequest(
 
   @Override
   public Set getLiveNodes() {
-if (liveNodes == null) {
-  throw new RuntimeException(
-  "We don't know of any live_nodes to fetch the"
-  + " latest live_nodes information from. "
-  + "If you think your Solr cluster is up and is accessible,"
-  + " you could try re-creating a new CloudSolrClient using 
working"
-  + " solrUrl(s) or zkHost(s).");
-}
 if (TimeUnit.SECONDS.convert((System.nanoTime() - liveNodesTimestamp), 
TimeUnit.NANOSECONDS)
 > getCacheTimeout()) {
-  for (String nodeName : liveNodes) {
-String baseUrl = Utils.getBaseUrlForNodeName(nodeName, urlScheme);
-try (SolrClient client = getSolrClient(baseUrl)) {
-  Set liveNodes = fetchLiveNodes(client);
-  this.liveNodes = (liveNodes);
-  liveNodesTimestamp = System.nanoTime();
-  return liveNodes;
-} catch (Exception e) {
-  log.warn("Attempt to fetch cluster state from {} failed.", baseUrl, 
e);
-}
-  }
+
+  if (liveNodes.stream()
+  .anyMatch((node) -> 
updateLiveNodes(URLUtil.getBaseUrlForNodeName(node, urlScheme
+return this.liveNodes;
+
+  log.warn(
+  "Attempt to fetch cluster state from all known live nodes {} failed. 
Trying backup nodes",
+  liveNodes);
+
+  if (configuredNodes.stream().anyMatch((node) -> 
updateLiveNodes(node.toString(

Review Comment:
   Shouldn't we check configuredNodes *first* so as to give the user the 
possibility of some control, basically addressing the conversation points in 
JIRA?



-- 
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-17342 Avoid loading from remote CDN [solr-site]

[via GitHub]

janhoy commented on PR #136:
URL: https://github.com/apache/solr-site/pull/136#issuecomment-2608368672

   I added licensing headers for CSS and LICENSE.txt files for the fonts to be 
more explicit


-- 
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-17631) Upgrade main to Lucene 10.x

[Jira]

 [ 
https://issues.apache.org/jira/browse/SOLR-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl updated SOLR-17631:
---
Priority: Blocker  (was: Major)

> Upgrade main to Lucene 10.x
> ---
>
> Key: SOLR-17631
> URL: https://issues.apache.org/jira/browse/SOLR-17631
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Ishan Chattopadhyaya
>Priority: Blocker
>  Labels: pull-request-available
> Fix For: main (10.0)
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Now that we have 9.8 release of Solr based on Lucene 9.12, we should move to 
> main + Lucene 10. Towards that, I've started on a WIP branch. Opening this 
> issue to track the effort needed for that.



--
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] chore(deps): update adobe.testing.s3mock to v3 (major) [solr]

[via GitHub]

malliaridis commented on PR #3002:
URL: https://github.com/apache/solr/pull/3002#issuecomment-260822

   This upgrade contains deprecation warnings for classes that are marked for 
removal. We may suppress the warnings, but an upgrade to JUnit 5 will be 
required for the next major upgrade (4.x).
   
   Additionally, a new test policy are required  and the tests still fail 
afterwards. So not straight-forward and likely has to be addressed in Jetty 
upgrade.


-- 
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-17342 Avoid loading from remote CDN [solr-site]

[via GitHub]

janhoy commented on PR #136:
URL: https://github.com/apache/solr-site/pull/136#issuecomment-2608272766

   Interestingly, the staging site already reports errors due to CSP.
   https://github.com/user-attachments/assets/fdfcc17e-4de2-4e34-bc1c-e4c46106b06e";
 />
   
   So after merge we'll be able to verify that these are now gone.


-- 
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] Prepare for running a separate Renovate workflow for branch_9x [solr]

[via GitHub]

janhoy opened a new pull request, #3057:
URL: https://github.com/apache/solr/pull/3057

   Now that main branch uses gradle version catalogs, dependency upgrades 
cannot be easily back ported to branch_9x anymore, unless the version catalogs 
are back ported as well.
   
   Also, many features are removed in main that still exist in branch_9x, so we 
will miss out on certain dep updates if we only rely on manual backports.
   
   Therefore I propose, and will test with dryRun, that @solrbot runs a 
separate 9x run, so we can merge them just like we do on main. Plan:
   
   * Place a `renovate.json` config in branch_9x, which targets old 
`versions.properties`
   * In solrbot repo, run a separate workflow that uses `baseBranch=branch_9x`
   * Do a dry run and verify that it works
   * Enable for branch_9x
   * Once Solr 10 is released, target instead latest `branch_9_x` which will 
have a long life in bugfix mode.


-- 
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] chore(deps): update dependency org.carrot2:carrot2-core to v4.6.0 [solr]

[via GitHub]

solrbot commented on PR #2983:
URL: https://github.com/apache/solr/pull/2983#issuecomment-2608653022

   ### Edited/Blocked Notification
   
   Renovate will not automatically rebase this PR, because it does not 
recognize the last commit author and assumes somebody else may have edited the 
PR.
   
   You can manually request rebase by checking the rebase/retry box above.
   
⚠️ **Warning**: custom changes will be lost.


-- 
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] chore(deps): update mockito to v5.15.2 [solr]

[via GitHub]

solrbot commented on PR #2998:
URL: https://github.com/apache/solr/pull/2998#issuecomment-2608656373

   ### Edited/Blocked Notification
   
   Renovate will not automatically rebase this PR, because it does not 
recognize the last commit author and assumes somebody else may have edited the 
PR.
   
   You can manually request rebase by checking the rebase/retry box above.
   
⚠️ **Warning**: custom changes will be lost.


-- 
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-17519: CloudSolrClient with HTTP ClusterState can forget live nodes and then fail [solr]

[via GitHub]

mlbiscoc commented on code in PR #2935:
URL: https://github.com/apache/solr/pull/2935#discussion_r1925986935


##
solr/solrj/src/java/org/apache/solr/client/solrj/impl/BaseHttpClusterStateProvider.java:
##
@@ -216,38 +236,42 @@ private SimpleOrderedMap submitClusterStateRequest(
 
   @Override
   public Set getLiveNodes() {
-if (liveNodes == null) {
-  throw new RuntimeException(
-  "We don't know of any live_nodes to fetch the"
-  + " latest live_nodes information from. "
-  + "If you think your Solr cluster is up and is accessible,"
-  + " you could try re-creating a new CloudSolrClient using 
working"
-  + " solrUrl(s) or zkHost(s).");
-}
 if (TimeUnit.SECONDS.convert((System.nanoTime() - liveNodesTimestamp), 
TimeUnit.NANOSECONDS)
 > getCacheTimeout()) {
-  for (String nodeName : liveNodes) {
-String baseUrl = Utils.getBaseUrlForNodeName(nodeName, urlScheme);
-try (SolrClient client = getSolrClient(baseUrl)) {
-  Set liveNodes = fetchLiveNodes(client);
-  this.liveNodes = (liveNodes);
-  liveNodesTimestamp = System.nanoTime();
-  return liveNodes;
-} catch (Exception e) {
-  log.warn("Attempt to fetch cluster state from {} failed.", baseUrl, 
e);
-}
-  }
+
+  if (liveNodes.stream()
+  .anyMatch((node) -> 
updateLiveNodes(URLUtil.getBaseUrlForNodeName(node, urlScheme
+return this.liveNodes;
+
+  log.warn(
+  "Attempt to fetch cluster state from all known live nodes {} failed. 
Trying backup nodes",
+  liveNodes);
+
+  if (configuredNodes.stream().anyMatch((node) -> 
updateLiveNodes(node.toString(

Review Comment:
   We could but to me it makes sense to try live nodes first unless this class 
was explicitly created as your JIRA proposal pointed, in that it only uses the 
passed URLs and nothing else. 
   
   I think it should be used as backup and go for fetching from live nodes 
first and assume by its name it is "live". If we do the opt in as a feature 
flag for dynamic node discovery then that gives them control. I'm fine with 
flipping it with configured first though if you feel strongly about 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

Re: [PR] SOLR-17519: CloudSolrClient with HTTP ClusterState can forget live nodes and then fail [solr]

[via GitHub]

dsmiley commented on PR #2935:
URL: https://github.com/apache/solr/pull/2935#issuecomment-2608306662

   I'll merge this in about a day as-is.


-- 
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]

[via GitHub]

sijuv commented on PR #2960:
URL: https://github.com/apache/solr/pull/2960#issuecomment-2608004442

   @dsmiley can you pls relook 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

Re: [PR] chore(deps): update opentelemetry to v1.46.0 [solr]

[via GitHub]

janhoy merged PR #2999:
URL: https://github.com/apache/solr/pull/2999


-- 
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-17631) Upgrade main to Lucene 10.x

[Jira]

 [ 
https://issues.apache.org/jira/browse/SOLR-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl updated SOLR-17631:
---
Fix Version/s: main (10.0)

> Upgrade main to Lucene 10.x
> ---
>
> Key: SOLR-17631
> URL: https://issues.apache.org/jira/browse/SOLR-17631
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: pull-request-available
> Fix For: main (10.0)
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Now that we have 9.8 release of Solr based on Lucene 9.12, we should move to 
> main + Lucene 10. Towards that, I've started on a WIP branch. Opening this 
> issue to track the effort needed for that.



--
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-17631) Upgrade main to Lucene 10.x

[Jira]

 [ 
https://issues.apache.org/jira/browse/SOLR-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jan Høydahl updated SOLR-17631:
---
Component/s: search

> Upgrade main to Lucene 10.x
> ---
>
> Key: SOLR-17631
> URL: https://issues.apache.org/jira/browse/SOLR-17631
> Project: Solr
>  Issue Type: Improvement
>  Components: search
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Now that we have 9.8 release of Solr based on Lucene 9.12, we should move to 
> main + Lucene 10. Towards that, I've started on a WIP branch. Opening this 
> issue to track the effort needed for that.



--
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]

[via GitHub]

dsmiley commented on PR #2960:
URL: https://github.com/apache/solr/pull/2960#issuecomment-2608897224

   note: you force-pushed to this PR.  Please don't do that; it resets the 
review state making it hard for me to see changes since my last review and if I 
try it's still possible an earlier commit was changed and I won't know it.  So 
never force-push to a PR that has been reviewed.


-- 
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] chore(deps): update dependency com.github.ben-manes.versions to v0.52.0 [solr]

[via GitHub]

solrbot opened a new pull request, #3058:
URL: https://github.com/apache/solr/pull/3058

   This PR contains the following updates:
   
   | Package | Type | Update | Change |
   |---|---|---|---|
   | com.github.ben-manes.versions | plugin | minor | `0.51.0` -> `0.52.0` |
   
   ---
   
   ### Configuration
   
   📅 **Schedule**: Branch creation - "* * * * *" (UTC), Automerge - At any time 
(no schedule defined).
   
   🚦 **Automerge**: Disabled by config. Please merge this manually once you are 
satisfied.
   
   ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry 
checkbox.
   
   🔕 **Ignore**: Close this PR and you won't be reminded about this update 
again.
   
   ---
   
- [ ] If you want to rebase/retry this PR, check this 
box
   
   ---
   
   This PR has been generated by [Renovate 
Bot](https://redirect.github.com/solrbot/renovate-github-action)
   

   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Re: [PR] SOLR-17447 : Support to early terminate a search based on maxHits per collector. [solr]

[via GitHub]

dsmiley commented on code in PR #2960:
URL: https://github.com/apache/solr/pull/2960#discussion_r1926430030


##
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:
   thinking out loud:  Perhaps we should do away with segmentTerminatedEarly as 
overly specific



##
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:
   When I see these other constants about TERMINATE_EARLY, this is what leads 
me to think that maxHitsTerminateEarly is a good name.



##
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:
   Somewhere we need documentation to differentiate the meaning of this vs 
partialResults.  To me, this _implies_ partialResults at the least and it may 
be redundant.



##
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:
   LongAdder is likely a better choice for this use-case



##
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:
   could use a comment like "assume the next collector, except 
EarlyTerminating, is the MaxScoreCollector".
   
   While you are changing this code, please rename `var4` which is an 
inexcusable variable name



##
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:
   this check is brittle since it can only possibly true if the *last* 
collector is earlyTerminatingCollector.  We may add others or re-order at some 
point.  Also, can we just depend on the exception above and set 
`qr.setTerminatedEarly(true);` there?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Re: [PR] SOLR-17447 : Support to early terminate a search based on maxHits per collector. [solr]

[via GitHub]

dsmiley commented on code in PR #2960:
URL: https://github.com/apache/solr/pull/2960#discussion_r1926442325


##
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:
   Okay you did in the ref guide... still a simple bit of javadoc here would be 
helpful



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

[jira] [Created] (SOLR-17631) Upgrade main to Lucene 10.x

[Ishan Chattopadhyaya (Jira)]

Ishan Chattopadhyaya created SOLR-17631:
---

 Summary: Upgrade main to Lucene 10.x
 Key: SOLR-17631
 URL: https://issues.apache.org/jira/browse/SOLR-17631
 Project: Solr
  Issue Type: Improvement
Reporter: Ishan Chattopadhyaya


Now that we have 9.8 release of Solr based on Lucene 9.12, we should move to 
main + Lucene 10. Towards that, I've started on a WIP branch. Opening this 
issue to track the effort needed for that.



--
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

[PR] SOLR-17631: Upgrade main to Lucene 10.x [solr]

[via GitHub]

chatman opened a new pull request, #3053:
URL: https://github.com/apache/solr/pull/3053

   [SOLR-17631](https://issues.apache.org/jira/browse/SOLR-17631)
   
   Upgrade main to Lucene 10.x
   
   Right now, I've fixed all compilation issues with core and test modules. 
Other modules still don't compile.
   On the tests front, I've fixed a few tests. There are the tests that still 
fail:
   
   ```
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.DisMaxRequestHandlerTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.update.processor.PreAnalyzedUpdateProcessorTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.TestRandomDVFaceting.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.DistributedIntervalFacetingTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.analysis.TestReversedWildcardFilterFactory.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.TestGroupingSearch.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.TestJoin.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.analysis.PathHierarchyTokenizerFactoryTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.TestDistributedSearch.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.BasicFunctionalityTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.TestDistributedGrouping.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.TestRandomFaceting.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.BasicDistributedZkTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.BasicDistributedZk2Test.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.DocValuesNotIndexedTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.handler.TestSnapshotCoreBackup.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.handler.component.DistributedSpellCheckComponentTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.cloud.TestSegmentSorting.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.handler.component.DebugComponentTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.handler.component.DistributedFacetPivotLargeTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.handler.component.DistributedFacetPivotWhiteBoxTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.search.TestTrieFacet.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.core.TestCodecSupport.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.search.facet.TestCloudJSONFacetSKG.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.core.SOLR749Test.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.handler.designer.TestSchemaDesignerAPI.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.spelling.SpellCheckCollatorTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.uninverting.TestFieldCacheVsDocValues.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.update.SolrIndexConfigTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.handler.component.DistributedFacetPivotSmallTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.search.facet.TestCloudJSONFacetJoinDomain.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.handler.component.DistributedFacetPivotSmallAdvancedTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.request.TestIntervalFaceting.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.uninverting.TestFieldCacheSortRandom.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.schema.PreAnalyzedFieldTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.handler.component.QueryElevationComponentTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.handler.component.StatsComponentTest.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.search.TestComplexPhraseLeadingWildcard.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.search.TestMissingGroups.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.search.TestRealTimeGet.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.request.TestWriterPerf.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.search.facet.TestJsonFacetRefinement.txt
   
./solr/core/build/test-results/test/outputs/OUTPUT-org.apache.solr.reques

[jira] [Commented] (SOLR-17631) Upgrade main to Lucene 10.x

[Ishan Chattopadhyaya (Jira)]

[ 
https://issues.apache.org/jira/browse/SOLR-17631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17915968#comment-17915968
 ] 

Ishan Chattopadhyaya commented on SOLR-17631:
-

[https://github.com/apache/solr/pull/3053]

^ Opened a WIP PR, help and support would be essential to see this through, 
since the scope and amount of changes are overwhelming.

 

> Upgrade main to Lucene 10.x
> ---
>
> Key: SOLR-17631
> URL: https://issues.apache.org/jira/browse/SOLR-17631
> Project: Solr
>  Issue Type: Improvement
>Reporter: Ishan Chattopadhyaya
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Now that we have 9.8 release of Solr based on Lucene 9.12, we should move to 
> main + Lucene 10. Towards that, I've started on a WIP branch. Opening this 
> issue to track the effort needed for that.



--
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