[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779074#comment-16779074 ] ASF subversion and git services commented on SOLR-12297: Commit feff459a1b9dd67197cd88cc450d53140ea9 in lucene-solr's branch refs/heads/branch_8x from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=feff459 ] SOLR-12297: Remove debugging System.out line > 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779073#comment-16779073 ] ASF subversion and git services commented on SOLR-12297: Commit 95a18460e80a0d9e9afd8126287acaea796c69aa in lucene-solr's branch refs/heads/branch_8_0 from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=95a1846 ] SOLR-12297: Remove debugging System.out line > 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16779071#comment-16779071 ] ASF subversion and git services commented on SOLR-12297: Commit 00c02290d58cab118c41e9fb01a458a466ea98d4 in lucene-solr's branch refs/heads/master from Cao Manh Dat [ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=00c0229 ] SOLR-12297: Remove debugging System.out line > 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550180#comment-16550180 ] ASF subversion and git services commented on SOLR-12297: Commit 3358d9366532020e4bde061d8a7cf39e1dd5c589 in lucene-solr's branch refs/heads/jira/http2 from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3358d93 ] SOLR-12297: Remove SupressSSL from Http2SolrClientTest > 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550169#comment-16550169 ] Cao Manh Dat commented on SOLR-12297: - I pushed my patch on branch jira/http2. This branch will be served like a *stepping stone* between the master branch and Mark Miller starburst branch. I will try to keep jira/http2 as close as master as possible (this will make merging in the future easier). In the same time, I will gradually split changes in starburst branch into smaller/testable parts then push it to jira/http2 branch. Anyone who interests at http2 for Solr can use jira/http2 branch but there is no backward-compatibility guarantee. > 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550165#comment-16550165 ] ASF subversion and git services commented on SOLR-12297: Commit a9aa50d60064163a91ba48bdc9d1ea5d33776d32 in lucene-solr's branch refs/heads/jira/http2 from [~caomanhdat] [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=a9aa50d ] SOLR-12297: Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests. > 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550110#comment-16550110 ] Cao Manh Dat commented on SOLR-12297: - On the second thought, let's cook everything in the "jira/http2" until everybody gets confident with the changes. > 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16550108#comment-16550108 ] Cao Manh Dat commented on SOLR-12297: - [~elyograg] , by using h2c, browser will fall back on using 1.1. So we won't see any problem here. > 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16549850#comment-16549850 ] Shawn Heisey commented on SOLR-12297: - bq. Commit the patch on master and enable Http2 support in "bin/solr" by modifying jetty-http.xml. Users may try to use it, and we may get some reports about problems of new client If we do not break 1.1 support in the server as we enable http2, and do not change the behavior of existing clients, I think this is a good option. Side note: I like the idea of using Mark's github project name for the new clients. StarBurstClient and CloudBurstClient for example. Those could be temporary names - fold the functionality back into HttpSolrClient and CloudSolrClient after everything stabilizes and eliminate the temporary names in the next major version. Additional side note: I haven't been able to put much time into it, but for SOLR-6733 and SOLR-6734 I was considering some ideas about how to enable TLS by default and make it a lot easier for users to create certificates or utilize certificates they already have, without needing to mess with Java's complicated repositories. Only mentioning this here because browsers are not implementing h2c. Not sure if that means it would just fall back to 1.1, or if there might be issues with the admin UI. > 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16548716#comment-16548716
]
Cao Manh Dat commented on SOLR-12297:
-
I attached a patch that pass {{ant precommit}}. The problem here I want to
discuss here is how we commit the patch. There are a couple of ways
# Commit the patch on master/branch_7x since {{Http2SolrClient}} are marked as
{{@experimental}}, and it can't be used to talk any solr servers. Users won't
use it.
# Commit the patch on master and enable Http2 support in "bin/solr" by
modifying {{jetty-http.xml}}. Users may try to use it, and we may get some
reports about problems of new client
# Commit the patch on jira/http2 branch, cook everything relate to http2 there.
> 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, 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547635#comment-16547635
]
Cao Manh Dat commented on SOLR-12297:
-
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547351#comment-16547351 ] Cao Manh Dat commented on SOLR-12297: - My idea for this ticket : * Add Http2SolrClient.java * A minimal test for Http2SolrClient based on BasicHttpSolrClient (this ensure the consistency in behaviors between Http2SolrClient and HttpSolrClient) * Enable Http2 in JettySolrRunner for *test environment* only. By doing that we can slowly introduce more supports on Http2 * All the changes will be tested for a very long time before we switch from Http to Http2 * Won't impact the current final build/release. I attached a *nearly finished* patch for this ticket : * Http2SolrClient's behaviors consistent with HttpSolrClient (include error handling, V2Request, multipart request, queryParams) * Add Http2SolrClientTest which mimic BasicHttpSolrClientTest I wonder that should I keep continue working on this issue, or create another one. Because my vision for this issue seems not match with others. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16540030#comment-16540030 ] David Smiley commented on SOLR-12297: - bq. I don’t plan on doing any of this piece mail. If it goes in, it will be like SolrCloud and be a full switch on a major version. Basically my branch is way better than the main branch. Either people will want to switch to it or they won’t. I'm kinda concerned by this. I think we all appreciate your heroics, but I think things need to be done in a way conducive to peer review. An all or nothing, take it or leave it, attitude concerns me. > 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16539770#comment-16539770
]
Cao Manh Dat commented on SOLR-12297:
-
I attached a *draft* patch for this ticket, changes compare to Mark's patch
include
* Minimal changes for JettySolrRunner
* In case of *https*, only http/1.1 will be supported (until we upgrade to jdk
9 or find a better way for handling ALPN)
* In case of *http*, HTTP/1.1 and HTTP2 (h2c) will be supported via http2
upgrade header
* Setting default {{SslContextFactory}} for {{Http2SolrClient}}
* Remove {{Http2SolrClient.makeResponse()}} (the method is buggy in counting
the time has passed and also lead to many different chance of other SolrRequest
classes)
* Remove the replacement of HttpSolrClient by Http2SolrClient
I'm thinking about an easier/more convenient solution for above last item. Ie :
making HttpSolrClient and Http2SolrClient swap-able.
> 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, 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16536973#comment-16536973 ] Mark Miller commented on SOLR-12297: Of course anyone can feel free to pull in what they want. I’m fully focused on addressing SolrCloud shortcomings and making a branch with passing tests. > 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: 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16536963#comment-16536963 ] Mark Miller commented on SOLR-12297: I don’t plan on doing any of this price mail. If it goes in, it will be like SolrCloud and be a full switch on a major version. Basically my branch is way better than the main branch. Either people will want to switch to it or they won’t. > 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: 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16536709#comment-16536709 ] Cao Manh Dat commented on SOLR-12297: - Hi, I skimmed through https://github.com/markrmiller/starburst/commit/f1134ee6581ffd11aea6c1413d0f4375aa8406d9.patch (the patch is huge). A large part of the patch is replacing HttpSolrClient by Http2SolrClient which I think can be postponed. Because * HttpSolrClient and Http2SolrClient will coexist, by replacing them we can't sure that HttpSolrClient will work after future changes * It makes the patch really large and hard to review. Therefore, in my opinion, we should focus on * Http2SolrClient.java and some minimal tests. * JettySolrRunner support booting up a server that accept http2 connection > 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: 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16501256#comment-16501256
]
Cao Manh Dat commented on SOLR-12297:
-
bq. One thing that may interest you that I would love help on is configuring
our Jetty instance for Http/2 as well as Http/1.1. Currently I'm just setting
everything up for JettySolrRunner and our core tests.
I think we should have a plan to move from Solr get loaded by Jetty to Solr
boot-up Jetty and do all the configuration. This will save us a lot of
difference between running Solr from {{bin/solr}} to testing Solr by using
JettySolrRunner.
> 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: 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500881#comment-16500881
]
Mark Miller commented on SOLR-12297:
You will see this in the logs when running under HTTP/2:
2018-06-04 16:15:56.319 INFO (main) [ ] o.e.j.s.AbstractConnector Started
ServerConnector@3300f4fd\{h2,[h2]}{0.0.0.0:8983}
Until SSL is working correctly or we configure to also server HTTP/1.1 on the
same port, browsers are not going to work with HTTP/2.
> 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: 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500859#comment-16500859 ] Mark Miller commented on SOLR-12297: You either have to switch the SolrHttpClient to use HTTP/1.1 or change etc/jetty-http.xml to use HTTP/2. [https://www.eclipse.org/jetty/documentation/9.4.x/http2-configuring.html] Id try changing the connection factory to org.eclipse.jetty.http2.server.HTTP2ServerConnectionFactory at a minimum. > 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: 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[ https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500779#comment-16500779 ] Shawn Heisey commented on SOLR-12297: - bq. Well the client will speak HTTP/2, but have you setup Jetty to run an HTTP/2 connector instead of HTTP/1.1? No, I just tried to get starburst started with minimal changes -- only the patch for ivy.The Jetty config is unchanged, so it's listening for 1.1 requests only. I did try to go into SolrCLI and explicitly tell it to use the 1.1 client, but either I didn't make the right change, or it failed to work. > 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: 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12297) Add Http2SolrClient, capable of HTTP/1.1, HTTP/2, and asynchronous requests.
[
https://issues.apache.org/jira/browse/SOLR-12297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500253#comment-16500253
]
Mark Miller commented on SOLR-12297:
{quote}If that works, great. I must be doing something wrong.
{quote}
For the Http2SolrClient, you would have to enable it in code - it uses a
different Transport class It's not setup to work with 1.1 with flipping what
Transport class is used in the code.
Thanks for fixing the hard coded versions, I'll look at that.
{quote}But creating a core will fail
{quote}
Well the client will speak HTTP/2, but have you setup Jetty to run an HTTP/2
connector instead of HTTP/1.1?
> 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: 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
