[
https://issues.apache.org/jira/browse/SOLR-15223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17432436#comment-17432436
]
Jan Høydahl commented on SOLR-15223:
------------------------------------
Question: Are all SolrClient variants migrated to the Http2 Jetty-client? I did
a quick walkthrough and found
{code:java}
HttpSolrClient Http2SolrClient
CloudSolrClient CloudHttp2SolrClient
HttpClusterStateProvider Http2ClusterStateProvider
LBHttpSolrClient LBHttp2SolrClient
ConcurrentUpdateSolrClient ConcurrentUpdateHttp2SolrClient {code}
These all look good, and have common code in a base class. However, this client
seems to be HTTP1 only
{code:java}
DelegationTokenHttpSolrClient {code}
And these classes are more utilities for setting up the ApacheHttpClient, I
don't know if they need HTTP2 counterparts:
{code:java}
HttpClientUtil
SolrHttpClientBuilder
SolrHttpClientContextBuilder {code}
So I guess the proposal is to deprecate these in 8.11, and remove from main
(along with the org.apache.httpcomponents:httpclient dependencies):
{code:java}
HttpSolrClient
CloudSolrClient
HttpClusterStateProvider
LBHttpSolrClient
ConcurrentUpdateSolrClient {code}
Question: Do we want to keep the Http2 naming or should we make the old names
as "wrappers", so that HttpSolrClient in 9.0 will actually use Http2SolrClient?
I guess users are already using the Http2-vairants in their code and it would
be too much to tell them to change that once again?
> Deprecate HttpSolrClient, mark httpcomponents dep as "optional" in SolrJ
> ------------------------------------------------------------------------
>
> Key: SOLR-15223
> URL: https://issues.apache.org/jira/browse/SOLR-15223
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: David Smiley
> Priority: Blocker
> Labels: newdev
> Fix For: main (9.0)
>
>
> Solr has had an HTTP/2 based SolrClient since 8.0. Maintaining both HTTP/1
> and HTTP/2 clients is a pain for maintenance of the project as it sometimes
> means duplicative (or partially implemented) work, especially for
> authentication but also sometimes metrics or tracing. Both adds extra
> dependencies for SolrJ and thus our users. It's difficult to grok a codebase
> using two different HTTP client frameworks.
> In this issue, mark HttpSolrClient (and related ones) as deprecated; point to
> HTTP/2 equivalents. Furthermore, mark the Apache "httpcomponents" libs as
> "optional" in the produced Maven pom.xml so that users have to explicitly
> opt-in to use it. Announce this in the Solr users list as well.
> Out of scope to this issue is completely cutting over within Solr itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
