[
https://issues.apache.org/jira/browse/SOLR-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17892565#comment-17892565
]
Jason Gerlowski edited comment on SOLR-17161 at 10/24/24 5:05 PM:
------------------------------------------------------------------
I guess I have a potential concern about moving the Jetty based clients into
their own artifact. Sorry to bring it to the table so late. (To be clear -
it's a "concern" and "request for info", and not a veto or anything like that.)
In short: it goes without saying how important defaults are in software, and
making the JDK-based client the only client available in 'solrj-core' will make
it the "effective default" for a lot of folks. Most users will start by just
grabbing 'solrj-core', and then their IDE's autocomplete will suggest
HttpJdkSolrClient (and _only_ HttpJdkSolrClient). That's a big deal! And I
worry about making that sort of change without a discussion about whether it's
our best option, holistically.
The JDK-based client is a clear winner on some concerns, e.g. dependency
footprint. But that's not the only concern users are likely to have:
* is there any difference in the perf characteristics of the two underlying
HttpClients?
* what sort of hooks does each offer into the request/response or client
lifecycle?
* do the clients differ in how much they let users customize threading or
connection-pooling behavior?
* is there a popularity gap, or are folks already pretty familiar with one
HttpClient in particular?
* any logging or tracing differences?
Has this sort of holistic discussion happened somewhere that I just missed? If
not, maybe we could have that here?
was (Author: gerlowskija):
I guess I have a potential concern about moving the Jetty based clients into
their own artifact. Sorry to bring it to the table so late. (To be clear -
it's a "concern" and "request for info", and not a veto or anything like that.)
In short: it goes without saying how important defaults are in software, and
making the JDK-based client the only client available in 'solrj-core' will make
it the "effective default" for a lot of folks. Most users will start by just
grabbing 'solrj-core', and then their IDE's autocomplete will suggest
HttpJdkSolrClient (and _only_ HttpJdkSolrClient). That's a big deal! And I
worry about making that sort of change without a discussion about whether it's
our best option, holistically.
The JDK-based client is a clear winner on some concerns, e.g. dependency
footprint. But that's not the only concern users are likely to have: is there
any difference in the perf characteristics of the two underlying HttpClients?
what sort of hooks does each offer into the request/response or client
lifecycle? do the clients differ in how much they let users customize threading
or connection-pooling behavior? is there a popularity gap, or are folks already
pretty familiar with one HttpClient in particular? any logging or tracing
differences?
Has this sort of holistic discussion happened somewhere that I just missed? If
not, maybe we could have that here?
> Separate out a solrj-jetty artifact (10.0)
> ------------------------------------------
>
> Key: SOLR-17161
> URL: https://issues.apache.org/jira/browse/SOLR-17161
> Project: Solr
> Issue Type: Sub-task
> Components: clients - java
> Reporter: Jan Høydahl
> Priority: Blocker
> Fix For: main (10.0)
>
>
> Given we have a native JDK based client in SOLR-599, we can separate out all
> {{Http2SolrClient}} and freiends with their jetty-client dependencies into a
> separate artifact {{{}solrj-jetty{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
