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

David Smiley closed SOLR-10466.
-------------------------------

Marking issue as closed *not* "reopened".  The code shipped in 9.3 thus any 
problems need to be new issues.

I suppose no action was taken from the above long discussion.  For now can we 
simply not use parallelStream in the specific scenario that led to test 
failures here?  That's the simplest agreeable change, even if the door is still 
open for the same bug pattern to occur.

I think Kevin asked why even bother with parallelStream for closing things; 
isn't closing things fast?  [~markrmil...@gmail.com] hopefully you are around 
to comment; I've observed you were pushing for parallel closing utilities, no 
doubt based on your performance experimentations.

> setDefaultCollection should be deprecated in favor of SolrClientBuilder 
> methods
> -------------------------------------------------------------------------------
>
>                 Key: SOLR-10466
>                 URL: https://issues.apache.org/jira/browse/SOLR-10466
>             Project: Solr
>          Issue Type: Sub-task
>          Components: SolrJ
>            Reporter: Jason Gerlowski
>            Assignee: Eric Pugh
>            Priority: Minor
>             Fix For: 7.0, main (10.0), 9.3
>
>          Time Spent: 8.5h
>  Remaining Estimate: 0h
>
> Now that builders are in place for {{SolrClients}}, the setters used in each 
> {{SolrClient}} can be deprecated, and their functionality moved over to the 
> Builders. This change brings a few benefits:
> - unifies {{SolrClient}} configuration under the new Builders. It'll be nice 
> to have all the knobs, and levers used to tweak {{SolrClient}}s available in 
> a single place (the Builders).
> - reduces {{SolrClient}} thread-safety concerns. Currently, clients are 
> mutable. Using some {{SolrClient}} setters can result in erratic and "trappy" 
> behavior when the clients are used across multiple threads.
> This subtask endeavors to change this behavior for the 
> {{setDefaultCollection}} setter on all {{SolrClient}} implementations.



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

Reply via email to