gerlowskija commented on PR #2689: URL: https://github.com/apache/solr/pull/2689#issuecomment-2375060453
All the approaches have downsides for sure, but for me personally, object allocation and the 'Closeable'-burden seem like the lesser evils. > unnecessary object creation "Cloud" clients are a bit different because of their ongoing ZK connections, but otherwise we've long assumed that our "Http" SolrClients are cheap and can/should be instantiated as-needed. That assumption underlies a lot of other decisions in SolrJ - e.g. the push to [make client impl's immutable and remove their setters](https://issues.apache.org/jira/browse/SOLR-8975). And IMO that makes sense - object allocations have a cost, but in terms of bottom-line performance, those are almost surely negligible compared to the much heavier, slower network requests the client is about to do. > responsible for closing And on the "they are responsible for closing" side - it is a bit of a burden, but it's one that Solr devs are used to paying attention to. And even for new devs, there's a lot of tooling built around enforcing this: IDEs will flag the unclosed Closeable, Solr's test-harness detects unclosed resources, etc. Requiring users to close out the client is a non-zero burden - I'm not waving that away. It's just a much smaller one IMO (and ["less surprising"](https://en.wikipedia.org/wiki/Principle_of_least_astonishment)) than giving callers a client that they immediately need to clone or know a special incantation to actually use. Not going to -1 anything here - I'd hate to come in late and blow up your hard work. But those are my 2c at least, from the perspective of "how would a caller likely expect this thing to work" -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
