Jason Gerlowski commented on SOLR-8975:

I've started work on this in earnest, after an embarassingly long delay.  As a 
change, it's reminiscent of SOLR-8097.  The change is simple conceptually, but 
involves many smaller changes to the tests, due to their use of SolrClients.

For instance, many tests choose a ResponseParser randomly, often changing the 
type frequently (each iteration through a for-loop) for added randomness.  In a 
"immutable-SolrClient-world" this approach isn't possible anymore, are at least 
it would require new clients to be created often.  This is relatively cheap for 
{{HttpSolrClient}}, but could prove to be prohibitive for {{CloudSolrClient}} 

I plan on pushing up a sample patch once I work through the work related to 
{{HttpSolrClient}}, so changes/suggestions can be discussed before I slog 
through the rest of the SolrClients.

> SolrClient setters should be deprecated in favor of SolrClientBuilder methods
> -----------------------------------------------------------------------------
>                 Key: SOLR-8975
>                 URL: https://issues.apache.org/jira/browse/SOLR-8975
>             Project: Solr
>          Issue Type: Improvement
>          Components: SolrJ
>            Reporter: Jason Gerlowski
>            Priority: Minor
> SOLR-8097 added a builder layer on top of each {{SolrClient}} implementation.
> 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 SolrClients 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 message was sent by Atlassian JIRA

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

Reply via email to