[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16549850#comment-16549850
]
Shawn Heisey commented on SOLR-12297:
-------------------------------------
bq. Commit the patch on master and enable Http2 support in "bin/solr" by
modifying jetty-http.xml. Users may try to use it, and we may get some reports
about problems of new client
If we do not break 1.1 support in the server as we enable http2, and do not
change the behavior of existing clients, I think this is a good option.
Side note: I like the idea of using Mark's github project name for the new
clients. StarBurstClient and CloudBurstClient for example. Those could be
temporary names - fold the functionality back into HttpSolrClient and
CloudSolrClient after everything stabilizes and eliminate the temporary names
in the next major version.
Additional side note: I haven't been able to put much time into it, but for
SOLR-6733 and SOLR-6734 I was considering some ideas about how to enable TLS by
default and make it a lot easier for users to create certificates or utilize
certificates they already have, without needing to mess with Java's complicated
repositories. Only mentioning this here because browsers are not implementing
h2c. Not sure if that means it would just fall back to 1.1, or if there might
be issues with the admin UI.
> 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, SOLR-12297.patch, 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
