[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16464835#comment-16464835
]
Shawn Heisey commented on SOLR-12297:
-------------------------------------
I'm generally on the "TLS everywhere" bandwagon for anything happening on the
Internet. But for internal services, especially those running java software, I
think h2c is a must-have, with an option to disable it. TLS configuration with
most Java software (including Solr and Jetty) is a little messy. I think we
need to make things a lot easier than they are now before we consider https out
of the box. At the very least we need scripts to automate keystore creation
and REALLY good documentation for using them.
On switching to the jetty client: Sounds good to me, especially if we're going
to continue to use Jetty on the server side for the foreseeable future. I
agree that they've been a great community to work with. The apache client
seems to be very good software, and although I haven't noticed any actual
*problems* in dealing with the httpcomponents community, the project moves very
slowly. That doesn't look like it's going to change anytime soon.
On ALPN and Java 8/9: The docs I've read say that the conscrypt ALPN solution
works in both Java 8 and Java 9, so we don't need to have different solutions
for those versions. (what do we know about Java 10?)
Side thought regarding http2: For installations on a LAN, http2 is not likely
to achieve much of a performance boost compared to http/1.1. TCP/HTTP
negotiation is cheap on a LAN, even when using speeds below gigabit. We
shouldn't let that be a justification for not keeping up with the advance of
technology.
Another side thought: Java 8 hits the "end of public updates" milestone in
January 2019. I think it would be a mistake for us to consider requiring Java
9 in any release that happens this year. And I think we should stick to major
releases for Java upgrades. The upgrade to Java 7 in the 4.8 minor release did
not generate the upheaval I thought it might, but that sort of change in a
minor release doesn't strike me as a good idea in general.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
