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

Shawn Heisey commented on SOLR-8975:
------------------------------------

General thoughts:

A lot of recent work, including this issue, is moving towards a goal of 
immutable SolrClient objects.  It's discussed in the comments here.  I think 
this is the right direction -- HttpClient has headed the same direction, 
beginning deprecation of anything related to mutable objects in version 4.3.

At the point where all the deprecated code goes away. I think that we should 
EXPLICITLY declare/document/enforce that SolrClient objects are immutable.

I don't know if that's something to do as part of this issue or as a new one.


> 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
>         Attachments: SOLR-8975.patch
>
>
> 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
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to