hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (HTTPCORE-424) A means to keep connections alive, even if fewer connections would suffice
Date Sun, 11 Dec 2016 15:51:58 GMT

     [ https://issues.apache.org/jira/browse/HTTPCORE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Oleg Kalnichevski resolved HTTPCORE-424.
    Resolution: Fixed

I added ConnPool policy parameter to control connection re-use policy:
* LIFO: re-use as few connections as possible making it possible for connections to become
idle and expire
* FIFO: re-use all connections equally preventing them from becoming idle and expiring. 

LIFO is still used by default.

Please review / test and let me know if that resolves the problem for you.


> 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
>            Assignee: Oleg Kalnichevski
>            Priority: Minor
>             Fix For: 5.0-alpha2
> 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

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message