[
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 it.
> 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: [email protected]
For additional commands, e-mail: [email protected]
