[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16464855#comment-16464855
]
Mark Miller commented on SOLR-12297:
------------------------------------
{quote}I think we need to make things a lot easier than they are now before we
consider https out of the box.
{quote}
Defaulting to having TLS on out of the box is completely unrelated to this
issue.
{quote}On ALPN and Java 8/9:
{quote}
We don't really need to worry about it now that they don't require the ALPN
boot jar stuff pre 9.
{quote}http2 is not likely to achieve much of a performance boost compared to
http/1.1. TCP/HTTP negotiation is cheap on a LAN
{quote}
My motivation for http2 is not TCP/HTTP negotiation or general performance - we
count on connection pooling largely, we are not an html web server - it's for
things like fewer connections with multiplexing and connection stability /
reuse simplicity. Of course HPACK compression and stuff is also nice to be able
to use. And we may find other benefits we can take advantage of. Multiplexing
is what I want most and support for that is what gives us hardier connection
reuse.
{quote}I think it would be a mistake for us to consider requiring Java 9
{quote}
When we move to Java 9 is also a separate issue from this JIRA and http2
wouldn't really factor in even if we needed Java9 for it, which we don't
anymore.
> 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
> 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: [email protected]
For additional commands, e-mail: [email protected]
