[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16464863#comment-16464863
]
Mark Miller edited comment on SOLR-12297 at 5/5/18 7:11 PM:
------------------------------------------------------------
Keep in mind that most of what you will read or see regarding Http2 is related
to standard web browser serving when we are looking to use it in the context of
a client server application.
The browsers say they will will require TLS with Http2 - that is a personal
decision. We won't require TLS with Http2. If you hit Solr with a browser and
no TLS, it will use Http1.1. We don't care about browser->solr and the Http
protocol.
Http2 also improves the performance of Http pipelining - this is the type of
thing that can make a new Http2 capable client as nice as
ConcurrenUpdateSolrClient but with actually good responses, especially when
paired with async. The Jetty HttpClient even works in a similar manner as CUSC
with per dentition queues and a thread pool and multiple connections
(multiplexed with http2!).
The bulk API that puts multiple updates in a single request will still be the
fastest way to bulk load, but the responses can never be good for that. You
have to consider the whole batch as good or bad depending on the response and
even if we added fine grained responses, for you some failure cases you would
still have to treat the bulk call as a single success/fail unit.
So that is what is exciting to me and part of why this was titled making a good
client for SolrCloud. This will let us make CloudSolrServer as good as it can
be. Right now it's lackluster and the alternative of using CUSC is a bitter
alternative. This will also let us improve the other clients when it comes to
internal communication and connection breaks and efficiency and performance,
etc, etc. One Http2SolrClient makes the whole world better - even without
http2, there will be improvements.
We also get better update streaming encoding than chunked and fewer connections
pooled. We also get all these other little improvements. It's just a better
server / client experience.
was (Author: markrmil...@gmail.com):
Keep in mind that most of what you will read or see regarding Http2 is related
to standard web browser serving when we are looking to use it in the context of
a client server application.
The browsers say they will will require TLS with Http2 - that is a personal
decision. We won't require TLS with Http2. If you hit Solr with a browser and
no TLS, it will use Http1.1. We don't care about browser->solr and the Http
protocol.
Http2 also improves the performance of Http2 pipelining - this is the type of
thing that can make a new Http2 capable client as nice as
ConcurrenUpdateSolrClient but with actually good responses, especially when
paired with async. Where we still won't compete with CUSC is with the bulk API,
where you add multiple documents in a single request (you can't get good
responses though).
We also get better update streaming encoding than chunked and fewer connections
pooled. We also get all these other little improvements. It's just a better
server / client experience.
> 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
> Assignee: 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
