[
https://issues.apache.org/jira/browse/HTTPCLIENT-1101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13053279#comment-13053279
]
Jon Moore commented on HTTPCLIENT-1101:
---------------------------------------
Ok, I modified AbstractHttpClient so we are not catching Throwables anymore,
although I'll still allow the ConnectionBackoffStrategy to be passed Throwables.
I think I'll proceed to merge down to the trunk and kill the branch, since I
think I've managed to isolate this work off in its own little area with a
minimal seam and with defaults that preserve the current behavior. I need to do
some testing with actual connection pools to convince myself this is
reasonable, but then otherwise I think the main thing needed would be
documentation to describe how to set up and use this (and possibly the addition
of some other convenience constructors, which we can talk about later).
> 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
> Reporter: Jon Moore
> Assignee: Jon Moore
> Fix For: 4.1 Final
>
>
> 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]
