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

Jason Gerlowski commented on SOLR-8975:
---------------------------------------

So I've taken a few (failed) cracks at this.  I believe in the idea, but 
putting the patch together has been difficult.  {{SolrClient}} is used in so 
many places that the change takes some time to put together, and is quite 
large.  Both of which contribute to the patch encountering merge conflicts from 
other development before it's even uploaded.

In hopes of mitigating this, I would like to break to break this issue down by 
setter.  Should help avoid/lessen some of the pitfalls I've run into so far.

> 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.3.15#6346)

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

Reply via email to