Any other perspectives on this? At this point, I've migrated all the tests to using the HTTP 2 versions of the SolrClients where that makes sense using the Builder pattern.
I'd like to get https://github.com/apache/solr/pull/1158 merged soon, so I can move on to updating more of Solr's core to using the Builder pattern. So more eyes on this would be great. On 2022/11/02 19:59:20 Jason Gerlowski wrote: > One counterpoint or downside to client immutability that's been raised > in the past - and what kindof stalled out my initial foray on > SOLR-8975 - is the high cost of creating CloudSolrClients. It'd be a > serious regression to force CloudSolrClient users to establish a new > ZK connection every time they want to send a request with a slightly > different read-timeout or whatever. > > Don't get me wrong - I'm still very much in favor of SolrClient > immutability - just mentioning the one roadblock I know of to get > people thinking about it. > > Best, > > Jason > > On Tue, Nov 1, 2022 at 10:17 PM Eric Pugh > <[email protected]> wrote: > > > > Here is the branch with the code that I worked on this evening: > > > > https://github.com/apache/solr/pull/1158 > > > > It’s listed as > > SOLR-16368-experiment-with-builder-to-simplify-client-creation, however > > that is because I didn’t know about SOLR-8975…. ;-). > > > > I would love some more eyes on it. > > > > > > > > > On Nov 1, 2022, at 6:32 PM, David Smiley <[email protected]> wrote: > > > > > > I think it would be beneficial for SolrClient to be immutable. Users > > > cache/pool them (even Solr itself via SolrClientCache) which can lead to > > > problems if somewhere code mutates them after they've been published. > > > SolrClients have Builders so we're already on the path to make this > > > happen. > > > > > > Years ago, Jason created a JIRA issue about this very thing: > > > https://issues.apache.org/jira/browse/SOLR-8975 > > > but it's rather hard, particularly across so many Solr tests that do > > > manipulations all over the place. I like that it's decomposed into > > > sub-JIRAs. These could easily be "newdev", by the way. > > > > > > Eric Pugh (unaware of SOLR-8975) started pulling a thread on this sweater, > > > and we've been chatting a bit about it. Anyway, I'm just posting here for > > > general awareness of the direction we're going in with SolrJ. Changes to > > > SolrJ are a high touch-point for our users so better to publicize. > > > > > > ~ David Smiley > > > Apache Lucene/Solr Search Developer > > > http://www.linkedin.com/in/davidwsmiley > > > > _______________________ > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > > http://www.opensourceconnections.com > > <http://www.opensourceconnections.com/> | My Free/Busy > > <http://tinyurl.com/eric-cal> > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > This e-mail and all contents, including attachments, is considered to be > > Company Confidential unless explicitly stated otherwise, regardless of > > whether attachments are marked as such. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
