[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16547635#comment-16547635
]
Cao Manh Dat edited comment on SOLR-12297 at 7/18/18 10:03 AM:
---------------------------------------------------------------
My idea for introducing http2 to Solr is
# Slowly introduce http2 support to *test environment* only (by setting
System.property variables) therefore users can't use any features of http2 in
solr server build.
# All public classes belong to http2 must be annotated as {{@experimental}}
# When all the features are mature enough we will do a full switch from old
http1 to http2
# All commits are done on master/branch_7x instead of baking a temporary
branch (ie: http2 branch), reasons
** It will the merge a lot easier since we seem to touch frequent update
classes
** It will force us to commit well-test code
** It will force us to not abandon it
** We can leverage current jenkins (as well as their reports) for knowing the
status of new tests for http2
*Note (need an agreement on this*): The only downside of this approach is solrj
and solr server will include several jars that they do not need (around 2 mb in
total for both).
was (Author: caomanhdat):
My idea for introducing http2 to Solr is
# Slowly introduce http2 support to *test environment* only (by setting
System.property variables) therefore users can't use any features of http2 in
solr server build.
# All public classes belong to http2 must be annotated as {{@experimental}}
# When all the features are mature enough we will do a full switch from old
http1 to http2
# All commits are done on master/branch_7x instead of baking a temporary
branch (ie: http2 branch), reasons
** It will the merge a lot easier since we seem to touch frequent update
classes
** It will force us to commit well-test code
** It will force us to not abandon it
** We can leverage current jenkins (as well as their reports) for knowing the
status of new tests for http2
The only downside of this approach is solrj and solr server will include
several jars that they do not need (around 2 mb in total for both).
> 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,
> 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]
