[
https://issues.apache.org/jira/browse/SOLR-16503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17625912#comment-17625912
]
David Smiley commented on SOLR-16503:
-------------------------------------
This migration is more about the software than it is the protocol; the latter
of which should be a matter of configuration. Solr is already part-way
migrated. To mitigate the risk you speak of, a user can use Jetty HttpClient
and tell it to use only HTTP 1.1, which is simpler (and less bugs likely?) than
HTTP 2. Looking at Http2SolrClient.createHttpClient, I see we use a system
property "solr.http1" to toggle this already.
> Switch UpdateShardHandler.getDefaultHttpClient to Jetty HTTP2
> -------------------------------------------------------------
>
> Key: SOLR-16503
> URL: https://issues.apache.org/jira/browse/SOLR-16503
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Priority: Major
>
> Much of Solr's remaining uses of Apache HttpClient (HTTP 1) is due to
> {{org.apache.solr.update.UpdateShardHandler#getDefaultHttpClient}} which
> underlies most Solr-to-Solr connectivity. This also underlies the
> {{{}CoreContainer.getSolrClientCache{}}}. Lets switch to Jetty (HTTP 2).
> ----
> In SolrClientCache in particular:
> Switch use of CloudLegacySolrClient.Builder to CloudSolrClient.Builder
> Switch use of HttpSolrClient.Builder to Http2SolrClient.Builder
> Undeprecate all the methods here. They should not have been deprecated in
> the first place.
> The constructor: switch from Apache HttpClient to a Jetty HttpClient.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
