You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2016/06/15 15:25:10 UTC
[jira] [Updated] (HTTPCORE-424) A means to keep connections alive,
even if fewer connections would suffice
[ https://issues.apache.org/jira/browse/HTTPCORE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski updated HTTPCORE-424:
---------------------------------------
Fix Version/s: 5.0
I think what we could make LIFO vs FIFO strategy configurable at construction time.
If you want it to happen sooner please do consider contributing a patch yourself. I'll have no bandwidth for anything other than bug fixes and HTTP/2 development for many months.
Oleg
> A means to keep connections alive, even if fewer connections would suffice
> --------------------------------------------------------------------------
>
> Key: HTTPCORE-424
> URL: https://issues.apache.org/jira/browse/HTTPCORE-424
> Project: HttpComponents HttpCore
> Issue Type: New Feature
> Components: HttpCore NIO
> Reporter: Tom Fitzhenry
> Priority: Minor
> Fix For: 5.0
>
>
> h3. Usecase
> I make 500req/s to the same server, whose response times average 5ms. This only needs 3 connections. This 500req/s occasionally bursts to 1000req/s, but as I only have 3 connections in my connection pool, I then have to establish a bunch of connections (let's say 17), at which point the latency suffers the cost of a TCP/SSL handshake.
> The rate then drops to the baseline 500req/s, but next time the 1000req/s burst occurs, I'll be ready right?! I have 20 connections in my pool, waiting for me to need them.
> No, I won't be ready. By the time the burst occurs, these extra connections have timed out, because they've not been used, and these connections are subject to TCP and HTTP time outs (both beyond my control).
> It would be nice to have a way to keep these connections active, so they don't idle out, ready for when I next see a burst of 1000req/s.
> h3. A possible implementation:
> A simple implementation would be to lease connections on a FIFO basis, rather than a LIFO basis (Apache HttpAsyncClient's current behaviour). With a FIFO policy, all connections would be kept active, so they would never idle out.
> Apache HttpAsyncClient uses a LinkedList, in LIFO mode: lines 83 and 129 of https://github.com/apache/httpcore/blob/4.4.x/httpcore-nio/src/main/java/org/apache/http/nio/pool/RouteSpecificPool.java#L83
> h3. Other HTTP clients:
> RxJava uses a Queue (FIFO): https://github.com/ReactiveX/RxJava/blob/2a8d6c75205b13cd9bef2b7f7d47723e1c86454e/src/main/java/rx/internal/util/ObjectPool.java#L28
> Vert.x uses a Queue (FIFO): https://github.com/eclipse/vert.x/blob/dbdcb3c785e9d8ff70dcce6a2e148cd3da6d15f6/src/main/java/io/vertx/core/http/impl/Http1xPool.java#L48
> async-http-client allows user to specify LIFO or FIFO: https://github.com/AsyncHttpClient/async-http-client/issues/1184
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org