Cao Manh Dat commented on SOLR-12297:

I attached a *draft* patch for this ticket, changes compare to Mark's patch 
* Minimal changes for JettySolrRunner
* In case of *https*, only http/1.1 will be supported (until we upgrade to jdk 
9 or find a better way for handling ALPN)
* In case of *http*, HTTP/1.1 and HTTP2 (h2c) will be supported via http2 
upgrade header
* Setting default {{SslContextFactory}} for {{Http2SolrClient}}
* Remove {{Http2SolrClient.makeResponse()}} (the method is buggy in counting 
the time has passed and also lead to many different chance of other SolrRequest 
* Remove the replacement of HttpSolrClient by Http2SolrClient

I'm thinking about an easier/more convenient solution for above last item. Ie : 
making HttpSolrClient and Http2SolrClient swap-able. 

> Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
> ----------------------------------------------------------------------------
>                 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
>         Attachments: SOLR-12297.patch, starburst-ivy-fixes.patch
> 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

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to