Performance analysis; Re: HTTPCORE-484
On Tue, 2018-07-17 at 19:39 +0800, King Silver wrote: > @ Oleg： > I think if read or write event concurrently with a timeout > event,there will be an exception in read or write event But this is bad. We do not want to shut down a channel only because some operation times out. > .handleIOEvent > method in InternalChannel class can > handle the exception appropriate。 > perhaps what i think is not right,please point it out,and i can > try to > improve the code. Before we can make any sensible decision about this feature I would like to know its impact on performance of the I/O reactor code. While working performance optimization of HttpCore 4.3 I put together a *non-scientific* benchmark that nevertheless measures i/o throughput of HttpCore, Jetty and Netty under similar load scenarios that can serve as a base line for comparative analysis of HttpCore performance. https://github.com/ok2c/httpcore-benchmark If you want to make a major contribution to the project please consider forking the benchmark code, upgrading it to the latest releases of all 3 frameworks and adding HttpCore 5 as the forth implementation. Once there are some numbers we can compare with, we can try running the latest HttpCore with your changes and see what kind of impact that makes on the benchmark results. Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCORE-536) duplicate connect method could be extract
[ https://issues.apache.org/jira/browse/HTTPCORE-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] silver9886 updated HTTPCORE-536: Priority: Major (was: Minor) > duplicate connect method could be extract > - > > Key: HTTPCORE-536 > URL: https://issues.apache.org/jira/browse/HTTPCORE-536 > Project: HttpComponents HttpCore > Issue Type: Improvement > Components: HttpCore NIO >Reporter: silver9886 >Priority: Major > > DefaultConnectingIOReactor and DefaultListeningIOReactor connect method are > same. > create abstractDefaultIOReactor class,put the connect code to the abstract > class. > AsyncServer and AsyncRequester connect method are same. > create abstractAsyncServerandRequester class,put the connect code to the > abstract class. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
HTTPCORE-484
@ Oleg： I think if read or write event concurrently with a timeout event,there will be an exception in read or write event .handleIOEvent method in InternalChannel class can handle the exception appropriate。 perhaps what i think is not right,please point it out,and i can try to improve the code.
[jira] [Resolved] (HTTPCLIENT-1934) H2TlsStrategy does not handle proxy connections correctly
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCLIENT-1934.
---
Resolution: Fixed
[~rschmitt] I committed a patch to master, which should fix the issue. Please
verify / re-test and close the issue.
Oleg
> H2TlsStrategy does not handle proxy connections correctly
> -
>
> Key: HTTPCLIENT-1934
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1934
> Project: HttpComponents HttpClient
> Issue Type: Bug
>Affects Versions: 5.0 Beta1
>Reporter: Ryan Schmitt
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> I'm setting up a CloseableHttpAsyncClient with an
> AsyncClientConnectionManager that sets up an H2TlsStrategy for the https
> scheme. In my integration tests, I have one test that calls a target host,
> [https://localhost:8444/,] over a proxy located at 127.0.0.7:8900. This
> mostly works: the client sends a CONNECT request to 127.0.0.7:8900 to set up
> a tunnel, and then sends a ClientHello to the target via the tunnel.
> The problem is that my HostnameVerifier is getting called back with the wrong
> hostname: instead of the target hostname ("localhost"), it is getting called
> back with the proxy hostname ("127.0.0.7"), and this then causes hostname
> verification to fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCLIENT-1934) H2TlsStrategy does not handle proxy connections correctly
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16546266#comment-16546266
]
ASF subversion and git services commented on HTTPCLIENT-1934:
-
Commit 50802106f6a3893029de66acdea8c0d07dc4bac9 in httpcomponents-client's
branch refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-client.git;h=5080210
]
HTTPCLIENT-1934: H2 TLS strategy passes wrong hostname to the hostname verifier
> H2TlsStrategy does not handle proxy connections correctly
> -
>
> Key: HTTPCLIENT-1934
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1934
> Project: HttpComponents HttpClient
> Issue Type: Bug
>Affects Versions: 5.0 Beta1
>Reporter: Ryan Schmitt
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> I'm setting up a CloseableHttpAsyncClient with an
> AsyncClientConnectionManager that sets up an H2TlsStrategy for the https
> scheme. In my integration tests, I have one test that calls a target host,
> [https://localhost:8444/,] over a proxy located at 127.0.0.7:8900. This
> mostly works: the client sends a CONNECT request to 127.0.0.7:8900 to set up
> a tunnel, and then sends a ClientHello to the target via the tunnel.
> The problem is that my HostnameVerifier is getting called back with the wrong
> hostname: instead of the target hostname ("localhost"), it is getting called
> back with the proxy hostname ("127.0.0.7"), and this then causes hostname
> verification to fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1934) H2TlsStrategy does not handle proxy connections correctly
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski updated HTTPCLIENT-1934:
--
Fix Version/s: 5.0 Beta2
> H2TlsStrategy does not handle proxy connections correctly
> -
>
> Key: HTTPCLIENT-1934
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1934
> Project: HttpComponents HttpClient
> Issue Type: Bug
>Affects Versions: 5.0 Beta1
>Reporter: Ryan Schmitt
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 5.0 Beta2
>
>
> I'm setting up a CloseableHttpAsyncClient with an
> AsyncClientConnectionManager that sets up an H2TlsStrategy for the https
> scheme. In my integration tests, I have one test that calls a target host,
> [https://localhost:8444/,] over a proxy located at 127.0.0.7:8900. This
> mostly works: the client sends a CONNECT request to 127.0.0.7:8900 to set up
> a tunnel, and then sends a ClientHello to the target via the tunnel.
> The problem is that my HostnameVerifier is getting called back with the wrong
> hostname: instead of the target hostname ("localhost"), it is getting called
> back with the proxy hostname ("127.0.0.7"), and this then causes hostname
> verification to fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Assigned] (HTTPCLIENT-1934) H2TlsStrategy does not handle proxy connections correctly
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski reassigned HTTPCLIENT-1934:
-
Assignee: Oleg Kalnichevski
> H2TlsStrategy does not handle proxy connections correctly
> -
>
> Key: HTTPCLIENT-1934
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1934
> Project: HttpComponents HttpClient
> Issue Type: Bug
>Affects Versions: 5.0 Beta1
>Reporter: Ryan Schmitt
>Assignee: Oleg Kalnichevski
>Priority: Major
>
> I'm setting up a CloseableHttpAsyncClient with an
> AsyncClientConnectionManager that sets up an H2TlsStrategy for the https
> scheme. In my integration tests, I have one test that calls a target host,
> [https://localhost:8444/,] over a proxy located at 127.0.0.7:8900. This
> mostly works: the client sends a CONNECT request to 127.0.0.7:8900 to set up
> a tunnel, and then sends a ClientHello to the target via the tunnel.
> The problem is that my HostnameVerifier is getting called back with the wrong
> hostname: instead of the target hostname ("localhost"), it is getting called
> back with the proxy hostname ("127.0.0.7"), and this then causes hostname
> verification to fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
Re: Porting IOReactorConfig from 4 to 5
On Mon, 2018-07-16 at 16:41 -0600, Gary Gregory wrote:
> Hi All:
>
> When I configure sockets for a ServerBootstrap I have to use a
> SocketConfig:
>
> final SocketConfig socketConfig = SocketConfig.custom()
> .setSoTimeout(Timeout.ofSeconds(15))
> .setTcpNoDelay(true)
> .build();
>
> server = ServerBootstrap.bootstrap()
> .setListenerPort(port)
> .setSocketConfig(socketConfig)
>
> .setHttpProcessor(HttpProcessors.server(NHttpFileServerTestRule.class
> .getCanonicalName()
> + "/1.1"))
> .register("*", new CustomHttpTestHandler())
> .setExceptionListener(ExceptionListener.STD_ERR)
> .create();
>
> But when I configure sockets in an AsyncServerBootstrap, I have to
> use an
> IOReactorConfig:
>
> IOReactorConfig config =
> IOReactorConfig.custom().setSoTimeout(15,
> TimeUnit.SECONDS).setTcpNoDelay(true).build();
>
> server = AsyncServerBootstrap.bootstrap()
> .setIOReactorConfig(config)
> .register("*", new
> AsyncServerRequestHandler>() {
>
> This is confusing, I should be able to use the same kind of object in
> both
> places.
>
I doubt this is realistic. Differences between SocketConfig and
IOReactorConfig simply reflect the differences between the classic
(blocking) and non-blocking i/o models.
Oleg
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
