lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shawn Heisey (JIRA)" <>
Subject [jira] [Commented] (SOLR-12297) Create a good SolrClient for SolrCloud paving the way for async requests, HTTP2, multiplexing, and the latest & greatest Jetty features.
Date Sat, 05 May 2018 16:54:00 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message