date:20250211

David Smiley created SOLR-17665:
---

 Summary: Perf regression: overhead of multiThreaded=false should 
be nothing
 Key: SOLR-17665
 URL: https://issues.apache.org/jira/browse/SOLR-17665
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 9.7
Reporter: David Smiley


SOLR-10734 introduced {{multiThreaded}} query param, defaulting to false, thus 
opt-in.  But there is still a serious performance impact; only setting 
{{indexSearcherExecutorThreads}} to -1 in solr.xml mitigates the regression.



--
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-17665) Perf regression: overhead of multiThreaded=false should be nothing



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

David Smiley updated SOLR-17665:

Description: SOLR-13350 introduced {{multiThreaded}} query param, 
defaulting to false, thus opt-in.  But there is still a serious performance 
impact; only setting {{indexSearcherExecutorThreads}} to -1 in solr.xml 
mitigates the regression.  (was: SOLR-10734 introduced {{multiThreaded}} query 
param, defaulting to false, thus opt-in.  But there is still a serious 
performance impact; only setting {{indexSearcherExecutorThreads}} to -1 in 
solr.xml mitigates the regression.)

> Perf regression: overhead of multiThreaded=false should be nothing
> --
>
> Key: SOLR-17665
> URL: https://issues.apache.org/jira/browse/SOLR-17665
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 9.7
>Reporter: David Smiley
>Priority: Major
>
> SOLR-13350 introduced {{multiThreaded}} query param, defaulting to false, 
> thus opt-in.  But there is still a serious performance impact; only setting 
> {{indexSearcherExecutorThreads}} to -1 in solr.xml mitigates the regression.



--
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] SolrTestCaseJ4: don't reset HttpClient SSL stuff [solr]



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

   I reverted the STCJ4 change; mentioning this PR number in my direct commit 
fix.
   
   And I filed this: https://issues.apache.org/jira/browse/SOLR-17666


-- 
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-17666) Run all tests with (or without) SSL per build.

David Smiley created SOLR-17666:
---

 Summary: Run all tests with (or without) SSL per build.
 Key: SOLR-17666
 URL: https://issues.apache.org/jira/browse/SOLR-17666
 Project: Solr
  Issue Type: Test
Reporter: David Smiley


It'd be easier to debug SSL related test failures if the entire build (all the 
tests) run a consistent SSL enabled/disabled choice, and we either have a 
dedicated build or randomly choose this at the start. We'd be able to use 
Develocity tags, thus aiding tracking patterns.  A failure of the build would 
also mean the reproducer line would print the SSL enablement, thus clarifying 
if SSL is a possible factor in the test failure (vs not an issue). The choice 
could be determined in gradle and passed only when enabled.  When invoking a 
test in an IDE, no longer will people need to familiarize themselves with 
Solr's insistence on SSL  secure randomization entropy, unless of course you 
are trying to debug an SSL failure.

Admittedly, a down-side is that a change that breaks SSL has a higher chance of 
getting merged without a PR validation noticing.

This approach could lead to simplified test infrastructure relating to this 
mechanism, as SSL doesn't need to be disabled/reset.  It just needs to be done 
once statically.



--
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] Update enabling-ssl.adoc - fix minor typo in example [solr]



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


##
solr/solr-ref-guide/modules/deployment-guide/pages/enabling-ssl.adoc:
##
@@ -245,7 +245,7 @@ Windows::
 
 [source,powershell]
 
-C:\> bin/solr.cmd --property urlSchema --value https --zk-host 
server1:2181,server2:2181,server3:2181

Review Comment:
   Does this need a `bin/solr cluster` here?



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

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

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


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

[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI

2025-02-11 Thread Jira



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

Jan Høydahl commented on SOLR-17659:


There are probably dozens of ways to find out it’s solr. But this is all 
backend and not related to new ui. If you want to work on solr stealth, that 
belong in some new jira.

> Implement basic authentication in Admin UI
> --
>
> Key: SOLR-17659
> URL: https://issues.apache.org/jira/browse/SOLR-17659
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI
>Reporter: Christos Malliaridis
>Priority: Major
>  Labels: new-ui, ui
>
> In the new UI one of the key features that is not implemented yet is user 
> authentication. In order to secure and securily access Solr, the user should 
> be able to authenticate against a Solr instance with basic credentials.
> h2. Task
> Implement basic user authentication (with credentials) according to the [new 
> designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1190-388&t=vMgOa9QlzQZSdjLf-1].
> h2. Acceptance Criteria
>  - The user can access a Solr instance that has user authentication enabled
>  - The user can at least authenticate with credentials (basic auth)
>  - The credentials form is displayed after the user has established a 
> connection with a Solr instance, that is, after a Solr instance was found
>  - The user can return to the start screen where the Solr URL was provided, 
> if he decides to abort the authentication step
>  - The user is no longer redirected to the dashboard or any other screen if 
> user authentication is required
>  - The credentials are used for any subsequent request
> h2. Additional Information
> The support for additional authentication options does not have to be 
> addressed in this issue. If it proves to be straight-forward, feel free to 
> implement additional auth options as well. Note that additional 
> authentication options will be added later, and therefore, the implementation 
> should be expandable.
> The credentials do not have to survive an application restart (desktop). 
> Storing credentials securely will be addressed in a separate issue.



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

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

Re: [PR] Update enabling-ssl.adoc - fix minor typo in example [solr]



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

   Okay, one thing to confirm, and then this looks good.   One shame is that 
this page 
https://solr.apache.org/guide/solr/latest/deployment-guide/solr-control-script-reference.html
 never mentions the "cluster" tool ;-(


-- 
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-17667) Simplify and cleanup zombie server logic in LBSolrClient



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

David Smiley commented on SOLR-17667:
-

Any relation to SOLR-17106?

> Simplify and cleanup zombie server logic in LBSolrClient
> 
>
> Key: SOLR-17667
> URL: https://issues.apache.org/jira/browse/SOLR-17667
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Houston Putman
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the Zombie server logic is quite complex, a list of alive servers 
> and a list of zombie servers. When moving servers between these lists, things 
> can get lost. Additionally, the logic is different when using a request that 
> contains a list of URLS. So zombies can be dropped always in some case, not 
> being added back to the alive list.
> It would be easier to have a list of allServers for a client, and a map of 
> zombieServers. If the server in allServers is not in the zombieServers map, 
> it can be considered alive.



--
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-17665) Perf regression: overhead of multiThreaded=false should be nothing



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

David Smiley commented on SOLR-17665:
-

It may sound like heresy to say this, but SolrIndexSearcher should perhaps not 
even extend Lucene IndexSearcher (in Solr 10).  It seems to barely be used as 
one, yet it needs to create them for at least query limits; probably delegating 
for doing multiThreaded as well even though it doesn't do that today.  It may 
be overriding methods that we didn't take care to do so for a IndexSearcher it 
creates.  Such an issue would show itself clearly (and we'd fix it) if we made 
this transition. 

> Perf regression: overhead of multiThreaded=false should be nothing
> --
>
> Key: SOLR-17665
> URL: https://issues.apache.org/jira/browse/SOLR-17665
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 9.7
>Reporter: David Smiley
>Priority: Major
>
> SOLR-13350 introduced {{multiThreaded}} query param, defaulting to false, 
> thus opt-in.  But there is still a serious performance impact; only setting 
> {{indexSearcherExecutorThreads}} to -1 in solr.xml mitigates the regression.



--
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] Update enabling-ssl.adoc - fix minor typo in example [solr]



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

   And after reviewing, I opened 
https://issues.apache.org/jira/browse/SOLR-17668...   


-- 
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-17668) bin/solr cluster command missing from bin/solr -h

2025-02-11 Thread Eric Pugh (Jira)

Eric Pugh created SOLR-17668:


 Summary: bin/solr cluster command missing from bin/solr -h
 Key: SOLR-17668
 URL: https://issues.apache.org/jira/browse/SOLR-17668
 Project: Solr
  Issue Type: Bug
  Components: cli
Affects Versions: 9.8, main (10.0)
Reporter: Eric Pugh
Assignee: Eric Pugh


After looking at [https://github.com/apache/solr/pull/3175/files] discovered 
the bin/solr -h misses the "cluster" command.



--
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] SolrTestCaseJ4: don't reset HttpClient SSL stuff [solr]



HoustonPutman commented on PR #3037:
URL: https://github.com/apache/solr/pull/3037#issuecomment-2651488289

   yeah, I don't mind the individual tests undoing it themselves, I think 
that's a good idea. Just revert the STCJ4 stuff.
   
   > Instead of flip-flopping from one test to the next, it'd be easier to 
track issues and debug if the entire build (all the tests selected) run a 
consistent SSL choice, and we either have a dedicated build or randomly choose 
this at the start.
   
   That would make debugging ALOT easier. Definitely worthy of a ticket.


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

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

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


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

[PR] Update enabling-ssl.adoc - fix minor typo in example [solr]



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

   
   
   # Description
   
   The example to update the Zookeeper properties has a typo as it uses 
urlSchema instead of urlScheme.
   
   # Solution
   
   Rename property in examples.
   
   # Tests
   
   None.
   
   # Checklist
   
   - [x] I have added documentation for the [Reference 
Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide)
   


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

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

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


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

Re: [PR] SOLR-11033: introduce multilingual configset [solr]



github-actions[bot] commented on PR #971:
URL: https://github.com/apache/solr/pull/971#issuecomment-2652326536

   This PR is now closed due to 60 days of inactivity after being marked as 
stale.  Re-opening this PR is still possible, in which case it will be marked 
as active again.


-- 
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-11033: introduce multilingual configset [solr]



github-actions[bot] closed pull request #971: SOLR-11033: introduce 
multilingual configset
URL: https://github.com/apache/solr/pull/971


-- 
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] Allow lsof and sockstat to detect if solr started successfully [solr]



github-actions[bot] commented on PR #2906:
URL: https://github.com/apache/solr/pull/2906#issuecomment-2652326430

   This PR has had no activity for 60 days and is now labeled as stale.  Any 
new activity will remove the stale label.  To attract more reviewers, please 
tag people who might be familiar with the code area and/or notify the 
d...@solr.apache.org mailing list. To exempt this PR from being marked as 
stale, make it a draft PR or add the label "exempt-stale". If left unattended, 
this PR will be closed after another 60 days of inactivity. Thank you for your 
contribution!


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

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

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


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

[jira] [Created] (SOLR-17667) Simplify and cleanup zombie server logic in LBSolrClient

2025-02-11 Thread Houston Putman (Jira)

Houston Putman created SOLR-17667:
-

 Summary: Simplify and cleanup zombie server logic in LBSolrClient
 Key: SOLR-17667
 URL: https://issues.apache.org/jira/browse/SOLR-17667
 Project: Solr
  Issue Type: Improvement
  Components: SolrJ
Reporter: Houston Putman


Currently the Zombie server logic is quite complex, a list of alive servers and 
a list of zombie servers. When moving servers between these lists, things can 
get lost. Additionally, the logic is different when using a request that 
contains a list of URLS. So zombies can be dropped always in some case, not 
being added back to the alive list.

It would be easier to have a list of allServers for a client, and a map of 
zombieServers. If the server in allServers is not in the zombieServers map, it 
can be considered alive.



--
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-17667: Simplify zombie logic in LBSolrClient [solr]



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

   https://issues.apache.org/jira/browse/SOLR-17667
   
   I made a patch for branch_9x first, since that's where the failures are 
occurring for TestLBHttp2SolrClient
   
   The changes are:
   
   - No alive map, just allServers map for the servers given to the client (not 
passed via a request)
   - The aliveness is determined by if the zombieMap contains the server
   - All modifications to allServers and zombieServers go through the same 
methods. These methods are synchronized, so the list and both maps will not be 
updated independently.
   - Since all modifications go through the same methods, we don't need to 
worry about dropping servers as the previous logic did.


-- 
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-17667) Simplify and cleanup zombie server logic in LBSolrClient

2025-02-11 Thread ASF GitHub Bot (Jira)



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

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

> Simplify and cleanup zombie server logic in LBSolrClient
> 
>
> Key: SOLR-17667
> URL: https://issues.apache.org/jira/browse/SOLR-17667
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Houston Putman
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the Zombie server logic is quite complex, a list of alive servers 
> and a list of zombie servers. When moving servers between these lists, things 
> can get lost. Additionally, the logic is different when using a request that 
> contains a list of URLS. So zombies can be dropped always in some case, not 
> being added back to the alive list.
> It would be easier to have a list of allServers for a client, and a map of 
> zombieServers. If the server in allServers is not in the zombieServers map, 
> it can be considered alive.



--
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-17659) Implement basic authentication in Admin UI

2025-02-11 Thread Gus Heck (Jira)



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

Gus Heck commented on SOLR-17659:
-

Ah but one thing perhaps I haven't made clear. I would like it to be hard for 
an attacker to identify that it IS solr at all... If it's not on port 8983, 
it's just something asking for login. (Probably we want a user configurable 
system name so people can have conficence they are talking to the right thing, 
but if that name doesn't include "solr" the guy who managed to sneak onto your 
network has no idea that that thing on 10.x.x.x:9993 is a valuable solr target.

> Implement basic authentication in Admin UI
> --
>
> Key: SOLR-17659
> URL: https://issues.apache.org/jira/browse/SOLR-17659
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI
>Reporter: Christos Malliaridis
>Priority: Major
>  Labels: new-ui, ui
>
> In the new UI one of the key features that is not implemented yet is user 
> authentication. In order to secure and securily access Solr, the user should 
> be able to authenticate against a Solr instance with basic credentials.
> h2. Task
> Implement basic user authentication (with credentials) according to the [new 
> designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1190-388&t=vMgOa9QlzQZSdjLf-1].
> h2. Acceptance Criteria
>  - The user can access a Solr instance that has user authentication enabled
>  - The user can at least authenticate with credentials (basic auth)
>  - The credentials form is displayed after the user has established a 
> connection with a Solr instance, that is, after a Solr instance was found
>  - The user can return to the start screen where the Solr URL was provided, 
> if he decides to abort the authentication step
>  - The user is no longer redirected to the dashboard or any other screen if 
> user authentication is required
>  - The credentials are used for any subsequent request
> h2. Additional Information
> The support for additional authentication options does not have to be 
> addressed in this issue. If it proves to be straight-forward, feel free to 
> implement additional auth options as well. Note that additional 
> authentication options will be added later, and therefore, the implementation 
> should be expandable.
> The credentials do not have to survive an application restart (desktop). 
> Storing credentials securely will be addressed in a separate issue.



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

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

[jira] [Commented] (SOLR-17298) Multithreaded search breaks limits, and possibly other things



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

David Smiley commented on SOLR-17298:
-

I doubt multiThreaded=true has its intended effect with query limits due to how 
[SolrIndexSearcher.search|https://github.com/apache/solr/blob/861a7761707457a65a3736ecc274cff3c8cb56e5/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L779]
 works (something I worked on).  Notice this method creates a new IndexSearcher 
using its simplest constructor, thus without the executor.

> Multithreaded search breaks limits, and possibly other things
> -
>
> Key: SOLR-17298
> URL: https://issues.apache.org/jira/browse/SOLR-17298
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: main (10.0), 9.7, 9x
>Reporter: Gus Heck
>Assignee: Gus Heck
>Priority: Blocker
>  Labels: pull-request-available
> Fix For: 9.7
>
>  Time Spent: 3h 40m
>  Remaining Estimate: 0h
>
> https://issues.apache.org/jira/browse/SOLR-13350 was merged to main somewhat 
> unexpectedly, and then back-ported to 9x without any response to feedback 
> from multiple committers, including feedback that
>  * By turning it on by default, it breaks the recently released CPU limits 
> (as shown by changes to unit tests).
>  * Incompatibility with timeAllowed, cpuTimeAllowed, segmentTerminateEarly, 
> GraphQuery, RankQuery and JoinQuery was not clearly documented
> I have not verified it yet, but I would also be worried about the health of 
> CPU time logging to be added in 
> https://issues.apache.org/jira/browse/SOLR-16986 after this change.
> Given that:
>  * Some of the above issues represent back compatibility breaks or potential 
> back compatibility breaks for released features
>  * The decision to break compatibility within the 9x release series deserves 
> a formal vote (or a fix).
>  * There has been no communication/response from the committer who merged 
> these changes since May 6 (aside from the backport to 9x on May 13) it seems 
> that this state may persist for some time.
> Therefore it appears necessary to file this issue to ensure anything but a 
> 9.6.1 is blocked until the above issues are sorted out. This ticket can serve 
> as a parent ticket to whatever various solutions are agreed upon.
> Multi-threaded search is an awesome feature that has taken a very long time 
> to be realized and is obviously desirable, but we have now placed ourselves 
> in an awkward position by not resolving these last few issues before back 
> porting.



--
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] Update enabling-ssl.adoc [solr]

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

Correcting keystore and key trust store file paths in the examples.

https://issues.apache.org/jira/browse/SOLR-X

# Description

Correcting SSL keystore and SSL trust store file paths in the examples.

# Solution

Added root directory to Linux and C:\ to windows configuration.

# Tests

Please describe the tests you've developed or run to confirm this patch
implements the feature or solves the problem.

# Checklist

Please review the following and check all that apply:

- [ ] 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.
- [ ] I have created a Jira issue and added the issue ID to my pull request
title.
- [ ] I have given Solr maintainers
[access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork)
to contribute to my PR branch. (optional but recommended, not available for
branches on forks living under an organisation)
- [ ] I have developed this patch against the `main` branch.
- [ ] I have run `./gradlew check`.
- [ ] I have added tests for my changes.
- [ ] I have added documentation for the [Reference
Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide)

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

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

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

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

[jira] [Commented] (SOLR-17665) Perf regression: overhead of multiThreaded=false should be nothing



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

David Smiley commented on SOLR-17665:
-

The simplest fix is to change indexSearcherExecutorThreads to -1.
But it'd be nicer to allow query-driven experimentation.  SolrIndexSearcher 
overrides a {{search}} method before handing off to Lucene; all Solr search 
flows through this.  This method already creates a new IndexSearcher in some 
cases; I could imagine it using another IndexSearcher exclusively created for 
multi-threaded search.  I also observe that with timeAllowed or other query 
limits, multiThreaded isn't going to have its effect.

> Perf regression: overhead of multiThreaded=false should be nothing
> --
>
> Key: SOLR-17665
> URL: https://issues.apache.org/jira/browse/SOLR-17665
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 9.7
>Reporter: David Smiley
>Priority: Major
>
> SOLR-13350 introduced {{multiThreaded}} query param, defaulting to false, 
> thus opt-in.  But there is still a serious performance impact; only setting 
> {{indexSearcherExecutorThreads}} to -1 in solr.xml mitigates the regression.



--
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] Update ktor to v3.1.0 [solr]



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

   This PR contains the following updates:
   
   | Package | Type | Update | Change |
   |---|---|---|---|
   | 
[io.ktor:ktor-serialization-kotlinx-json](https://redirect.github.com/ktorio/ktor)
 | dependencies | minor | `3.0.3` -> `3.1.0` |
   | [io.ktor:ktor-client-js](https://redirect.github.com/ktorio/ktor) | 
dependencies | minor | `3.0.3` -> `3.1.0` |
   | [io.ktor:ktor-client-core](https://redirect.github.com/ktorio/ktor) | 
dependencies | minor | `3.0.3` -> `3.1.0` |
   | 
[io.ktor:ktor-client-content-negotiation](https://redirect.github.com/ktorio/ktor)
 | dependencies | minor | `3.0.3` -> `3.1.0` |
   | [io.ktor:ktor-client-cio](https://redirect.github.com/ktorio/ktor) | 
dependencies | minor | `3.0.3` -> `3.1.0` |
   
   ---
   
   ### Configuration
   
   📅 **Schedule**: Branch creation - "* * * * *" (UTC), Automerge - At any time 
(no schedule defined).
   
   🚦 **Automerge**: Disabled by config. Please merge this manually once you are 
satisfied.
   
   ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry 
checkbox.
   
   🔕 **Ignore**: Close this PR and you won't be reminded about these updates 
again.
   
   ---
   
- [ ] If you want to rebase/retry this PR, check this 
box
   
   ---
   
   This PR has been generated by [Renovate 
Bot](https://redirect.github.com/solrbot/renovate-github-action)
   

   


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

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

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


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

[jira] [Commented] (SOLR-17659) Implement basic authentication in Admin UI



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

David Smiley commented on SOLR-17659:
-

I completely agree with Jan.  This issue is about the front-end, not the 
backend.  As such, if the front-end somehow gets info from the back-end, it's 
fair-game to display it.

> Implement basic authentication in Admin UI
> --
>
> Key: SOLR-17659
> URL: https://issues.apache.org/jira/browse/SOLR-17659
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI
>Reporter: Christos Malliaridis
>Priority: Major
>  Labels: new-ui, ui
>
> In the new UI one of the key features that is not implemented yet is user 
> authentication. In order to secure and securily access Solr, the user should 
> be able to authenticate against a Solr instance with basic credentials.
> h2. Task
> Implement basic user authentication (with credentials) according to the [new 
> designs|https://www.figma.com/design/VdbEfcWQ8mirFNquBzbPk2/Apache-Solr-Admin-UI-v2-Concept?node-id=1190-388&t=vMgOa9QlzQZSdjLf-1].
> h2. Acceptance Criteria
>  - The user can access a Solr instance that has user authentication enabled
>  - The user can at least authenticate with credentials (basic auth)
>  - The credentials form is displayed after the user has established a 
> connection with a Solr instance, that is, after a Solr instance was found
>  - The user can return to the start screen where the Solr URL was provided, 
> if he decides to abort the authentication step
>  - The user is no longer redirected to the dashboard or any other screen if 
> user authentication is required
>  - The credentials are used for any subsequent request
> h2. Additional Information
> The support for additional authentication options does not have to be 
> addressed in this issue. If it proves to be straight-forward, feel free to 
> implement additional auth options as well. Note that additional 
> authentication options will be added later, and therefore, the implementation 
> should be expandable.
> The credentials do not have to survive an application restart (desktop). 
> Storing credentials securely will be addressed in a separate issue.



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

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

[jira] [Commented] (SOLR-17665) Perf regression: overhead of multiThreaded=false should be nothing



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

Luke Kot-Zaniewski commented on SOLR-17665:
---

As [~dsmiley] alluded already, the reason simply setting multiThreaded=false 
doesn't revert to previous behavior/performance is because once 
indexSearcherExecutorThreads>0, the solr core will create this new TPE and pass 
it to lucene's IndexSearcher. Once Lucene's IndexSearcher has an Executor, it 
is liable to use it in ways that aren't governed by solr's multiThreaded flag. 
One way to enforce that multiThreaded completely controls this feature is to 
create a separate IndexSearcher (via SolrIndexSearcher) without any kind of 
Executor that gets invoked when multiThreaded=false. 

Still, the performance issues are quite puzzling and troubling.. In case it is 
of any use, I am attaching JFR profiles of 3 different configurations of the 
benchmarks discussed in the mailing list under "Identifying performance issues 
in Solr 9.7/9.8":

1. multiThreaded=false, indexSearcherExecutorThreads=cores (default) 
[^flight-9.8-mt-false-executor-enabled.jfr]
2. multiThreaded=false, indexSearcherExecutorThreads=-1 
[^flight-9.8-executor-disabled.jfr]
3. multiThreaded=true, indexSearcherExecutorThreads=cores (default) 
[^flight-9.8-mt-true.jfr] 
 

One spot I noticed a large divergence is in the TermStates which the benchmark 
term queries depend on. The reason I looked at TermStates more closely is that 
it is the one part of lucene (that I could find) that parallelizes things on 
that aforementioned executor even if you set multiThreaded=false in your 
requests. I was surprised that disabling the thread-pool causes significantly 
_more_ samples to appear in TermStates::build and that this _reduces_ latency 
of each query. In the jfr with multithreaded=false but with 
indexSearcherExecutorThreads=cores there are quite fewer samples captured in 
TermStates::build yet the term queries suffer from worse latency.

Worst of all, perhaps, is that setting multiThreaded=true doesn't seem to 
really improve performance on my 16 core machine (WSL on windows with 16 core 
i7-11850h). Perhaps I am missing something from my set-up but figured I'd share 
the testing I've done.

> Perf regression: overhead of multiThreaded=false should be nothing
> --
>
> Key: SOLR-17665
> URL: https://issues.apache.org/jira/browse/SOLR-17665
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 9.7
>Reporter: David Smiley
>Priority: Major
> Attachments: flight-9.8-executor-disabled.jfr, 
> flight-9.8-mt-false-executor-enabled.jfr, flight-9.8-mt-true.jfr
>
>
> SOLR-13350 introduced {{multiThreaded}} query param, defaulting to false, 
> thus opt-in.  But there is still a serious performance impact; only setting 
> {{indexSearcherExecutorThreads}} to -1 in solr.xml mitigates the regression.



--
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-17665) Perf regression: overhead of multiThreaded=false should be nothing



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

Luke Kot-Zaniewski updated SOLR-17665:
--
Attachment: flight-9.8-executor-disabled.jfr
flight-9.8-mt-false-executor-enabled.jfr
flight-9.8-mt-true.jfr

> Perf regression: overhead of multiThreaded=false should be nothing
> --
>
> Key: SOLR-17665
> URL: https://issues.apache.org/jira/browse/SOLR-17665
> Project: Solr
>  Issue Type: Bug
>  Components: search
>Affects Versions: 9.7
>Reporter: David Smiley
>Priority: Major
> Attachments: flight-9.8-executor-disabled.jfr, 
> flight-9.8-mt-false-executor-enabled.jfr, flight-9.8-mt-true.jfr
>
>
> SOLR-13350 introduced {{multiThreaded}} query param, defaulting to false, 
> thus opt-in.  But there is still a serious performance impact; only setting 
> {{indexSearcherExecutorThreads}} to -1 in solr.xml mitigates the regression.



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

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

[jira] [Comment Edited] (SOLR-17665) Perf regression: overhead of multiThreaded=false should be nothing



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

Luke Kot-Zaniewski edited comment on SOLR-17665 at 2/11/25 9:49 PM:


As [~dsmiley] alluded already, the reason simply setting multiThreaded=false 
doesn't revert to previous behavior/performance is because once 
indexSearcherExecutorThreads>0, the solr core will create this new TPE and pass 
it to lucene's IndexSearcher. Once Lucene's IndexSearcher has an Executor, it 
is liable to use it in ways that aren't governed by solr's multiThreaded flag. 
One way to enforce that multiThreaded completely controls this feature is to 
create a separate IndexSearcher (via SolrIndexSearcher) without any kind of 
Executor that gets invoked when multiThreaded=false.

Still, the performance issues are quite puzzling and troubling.. In case it is 
of any use, I am attaching JFR profiles of 3 different configurations of the 
benchmarks discussed in the mailing list under "Identifying performance issues 
in Solr 9.7/9.8":

1. multiThreaded=false, indexSearcherExecutorThreads=cores (default) 
[^flight-9.8-mt-false-executor-enabled.jfr]
2. multiThreaded=false, indexSearcherExecutorThreads=-1 
[^flight-9.8-executor-disabled.jfr]
3. multiThreaded=true, indexSearcherExecutorThreads=cores (default) 
[^flight-9.8-mt-true.jfr]

One spot I noticed a large divergence is in the TermStates which the benchmark 
term queries depend on. The reason I looked at TermStates more closely is that 
it is the one part of lucene (that I could find) that parallelizes things on 
that aforementioned executor even if you set multiThreaded=false in your 
requests. I was surprised that disabling the thread-pool causes significantly 
_more_ samples to appear in TermStates::build and that this _reduces_ latency 
of each query. In the jfr with multithreaded=false but with 
indexSearcherExecutorThreads=cores there are quite fewer samples captured in 
TermStates::build yet the term queries suffer from worse latency.

Setting multiThreaded=true doesn't seem to really improve performance on my 16 
core machine (WSL on windows with 16 core i7-11850h) of this benchmark. The 
benchmark appears to run 1 query at a time so it's possible the benefits of 
parallelism aren't ever reached with this level of load (low cpu-utilization 
reported in the JFR recording seems to support this). But the ~4X degradation 
of single-query latency with the custom executor enabled is suspicious.


was (Author: JIRAUSER304885):
As [~dsmiley] alluded already, the reason simply setting multiThreaded=false 
doesn't revert to previous behavior/performance is because once 
indexSearcherExecutorThreads>0, the solr core will create this new TPE and pass 
it to lucene's IndexSearcher. Once Lucene's IndexSearcher has an Executor, it 
is liable to use it in ways that aren't governed by solr's multiThreaded flag. 
One way to enforce that multiThreaded completely controls this feature is to 
create a separate IndexSearcher (via SolrIndexSearcher) without any kind of 
Executor that gets invoked when multiThreaded=false. 

Still, the performance issues are quite puzzling and troubling.. In case it is 
of any use, I am attaching JFR profiles of 3 different configurations of the 
benchmarks discussed in the mailing list under "Identifying performance issues 
in Solr 9.7/9.8":

1. multiThreaded=false, indexSearcherExecutorThreads=cores (default) 
[^flight-9.8-mt-false-executor-enabled.jfr]
2. multiThreaded=false, indexSearcherExecutorThreads=-1 
[^flight-9.8-executor-disabled.jfr]
3. multiThreaded=true, indexSearcherExecutorThreads=cores (default) 
[^flight-9.8-mt-true.jfr] 
 

One spot I noticed a large divergence is in the TermStates which the benchmark 
term queries depend on. The reason I looked at TermStates more closely is that 
it is the one part of lucene (that I could find) that parallelizes things on 
that aforementioned executor even if you set multiThreaded=false in your 
requests. I was surprised that disabling the thread-pool causes significantly 
_more_ samples to appear in TermStates::build and that this _reduces_ latency 
of each query. In the jfr with multithreaded=false but with 
indexSearcherExecutorThreads=cores there are quite fewer samples captured in 
TermStates::build yet the term queries suffer from worse latency.

Worst of all, perhaps, is that setting multiThreaded=true doesn't seem to 
really improve performance on my 16 core machine (WSL on windows with 16 core 
i7-11850h). Perhaps I am missing something from my set-up but figured I'd share 
the testing I've done.

> Perf regression: overhead of multiThreaded=false should be nothing
> --
>
> Key: SOLR-17665
> URL: https://issues.apache.org/jira/browse/SOLR-17665
> Project

[jira] [Commented] (SOLR-17667) Simplify and cleanup zombie server logic in LBSolrClient

2025-02-11 Thread Houston Putman (Jira)



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

Houston Putman commented on SOLR-17667:
---

It's related in terms of this logic has a lot of room for improvement, but 
these are entirely different improvements. I'm only fixing and improving how 
the internal state management is done, not changing the contract with the users 
or giving them more customization options.

> Simplify and cleanup zombie server logic in LBSolrClient
> 
>
> Key: SOLR-17667
> URL: https://issues.apache.org/jira/browse/SOLR-17667
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Houston Putman
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently the Zombie server logic is quite complex, a list of alive servers 
> and a list of zombie servers. When moving servers between these lists, things 
> can get lost. Additionally, the logic is different when using a request that 
> contains a list of URLS. So zombies can be dropped always in some case, not 
> being added back to the alive list.
> It would be easier to have a list of allServers for a client, and a map of 
> zombieServers. If the server in allServers is not in the zombieServers map, 
> it can be considered alive.



--
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-17665) Perf regression: overhead of multiThreaded=false should be nothing