[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16496880#comment-16496880
]
Shawn Heisey commented on SOLR-12297:
-------------------------------------
In my travels trying to get the server working on starburst, I came across a
comment on this issue:
https://github.com/eclipse/jetty.project/issues/1308#issuecomment-277940891
Where it is revealed that jetty's Http2Client *only* talks to http2 servers.
The documentation link in the comment suggests that it might only be possible
for a single client object to speak one http version, because its transport
appears to be explicitly set.
If one jetty client object can only speak either http/1.1 or http/2, then that
causes us some difficulties. SolrClient implementations and the shard handler
will need to support both versions, and explicitly decide which version to use
for all connections. If we don't do that, rolling upgrades would be
impossible. A mixed-version cluster will have to force usage of the http/1.1
client until the entire cluster is upgraded.
Asking about this on the jetty IRC channel, this is the response I got:
{noformat}
10:59 <@jmcconnell> @elyograg @sbordet was working on a unified client at one
point, I think that was targeted for Jetty 10 but he would
know the latest and greatest on that
{noformat}
> Create a good SolrClient for SolrCloud paving the way for async requests,
> HTTP2, multiplexing, and the latest & greatest Jetty features.
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-12297
> URL: https://issues.apache.org/jira/browse/SOLR-12297
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Mark Miller
> Assignee: Mark Miller
> Priority: Major
>
> Blocking or async support as well as HTTP2 compatible with multiplexing.
> Once it supports enough and is stable, replace internal usage, allowing
> async, and eventually move to HTTP2 connector and allow multiplexing. Could
> support HTTP1.1 and HTTP2 on different ports depending on state of the world
> then.
> The goal of the client itself is to work against HTTP1.1 or HTTP2 with
> minimal or no code path differences and the same for async requests (should
> initially work for both 1.1 and 2 and share majority of code).
> The client should also be able to replace HttpSolrClient and plug into the
> other clients the same way.
> I doubt it would make sense to keep ConcurrentUpdateSolrClient eventually
> though.
> I evaluated some clients and while there are a few options, I went with
> Jetty's HttpClient. It's more mature than Apache HttpClient's support (in 5
> beta) and we would have to update to a new API for Apache HttpClient anyway.
> Meanwhile, the Jetty guys have been very supportive of helping Solr with any
> issues and I like having the client and server from the same project.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
