[
https://issues.apache.org/jira/browse/HTTPCLIENT-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski resolved HTTPCLIENT-1101.
-------------------------------------------
Resolution: Fixed
Fix Version/s: (was: Future)
4.5.4
I guess we have to call it as good as it gets.
Oleg
> 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 (classic)
> Reporter: Jon Moore
> Assignee: Jon Moore
> Fix For: 4.5.4
>
>
> 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 was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
