hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Moore (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1101) adaptive connection pool sizing
Date Fri, 17 Jun 2011 14:01:47 GMT

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

Jon Moore commented on HTTPCLIENT-1101:

@Oleg: ok, will do on the branch.

I did initially want to keep it in the connection manager, although adjusting the pool size
means you need to know what happened when you *used* the request (did you get an I/O exception,
did you get a valid HTTP response that nonetheless indicates a backoff signal, etc.), so there
has to be some kind of hook in the code that uses the connections (currently in AbstractHttpClient,
but I guess could also be in the RequestDirector) that provides the observation point for
the control mechanism.

Let me get what I've got into the branch and then see if there's a better way to go about

> 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