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] [Commented] (HTTPCLIENT-1101) adaptive connection pool sizing
Date Wed, 22 Jun 2011 11:10:47 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053182#comment-13053182

Oleg Kalnichevski commented on HTTPCLIENT-1101:

Hi Jon

Looks very promising. Great stuff! Feel free to merge the changes down to the trunk or proceed
with the development on the branch until you are comfortable with the overall design. One
thing I thought I should mention though. I personally feel uncomfortable with code that catches
Errors or works with Throwables instead of Exceptions. Applications ought not mess with Errors
in my opinion. There is no point trying to adjust the size of the connection pool if the application
just caused a stack overflow or ran out of memory.


> adaptive connection pool sizing
> -------------------------------
>                 Key: HTTPCLIENT-1101
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1101
>             Project: HttpComponents HttpClient
>          Issue Type: New Feature
>          Components: HttpClient
>    Affects Versions: Future
>            Reporter: Jon Moore
>            Assignee: Jon Moore
> I'm currently working on a patch (wrote most of it on a cross-country flight) that will
adapt the size of a per-route connection pool based on the interactions we see from that particular
host. There's a sample implementation that does TCP-style additive increase/multiplicative
decrease (AIMD) adaptation of the per-route pool where successful requests allow probing for
more connections, but socket timeouts, connection timeouts, and 503s all result in backoffs.
> I'm hoping to hook this up for a demo to show multiple clients hitting a server with
a fixed capacity where we can kill one client and the others then increase their pool sizes
to take advantage of the unused server capacity. We can then restart the client and see things
rebalance again. This would enable folks to use HttpClient e.g. in an application server cluster
setting, where we wouldn't have to precompute or adjust the connection pool sizes as we add/remove
nodes from the cluster (whether intentionally or via failures).
> Once I get that proof of concept working I'll post a patch for review. Roughly the patch
hooks into AbstractHttpClient to look either for an HttpResponse or to catch an Exception,
then hands those events off to another object to decide whether to backoff or not. In turn,
we dynamically manage a ConnPerRouteBean to adjust the maxPerRoute to allow for the pool to
grow or shrink naturally with TSSCM. Default implementations are all backwards compatible
and don't change behavior.
> Thoughts?

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


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

View raw message