I spent a bit more time on https://github.com/apache/solr/pull/1158 to have it be focused on moving us to using the Builder pattern for our various SolrClients. I've renamed the PR to "SOLR-16368: Use Builder Pattern with Solr Clients" which I think communicates it a bit better. I'd like to get this merged before it gets any bigger, and was thinking mid next week, say Nov 30th if folks don't have any objections? Obviously if there are concerns etc please speak up, I don't want to rush it!
Once this is in, I'd like to tackle removing the deprecated methods on our various SolrClients, and if we can get that done, then those classes will be a lot shorter and easier to read. Is removing the deprecated methods something that can only happen on main? On 2022/11/10 12:51:07 Eric Pugh wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
