hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl A. Dunham" <ht...@strategyforward.com>
Subject Re: CRLF and Connection: close
Date Fri, 21 Mar 2003 07:17:39 GMT

I did a fairly rough version of your first suggestion. It basically adds a 
list of free connections across hosts, and keeps a seperate counter. It seems 
to be working pretty well, although it should probably use a smarter 
algorithm for determining which connection to close, like the one least often 
used, and with no one waiting to get it, etc.

This *might* be useable for both types of uses, although it would suffer a 
slight performance hit for users who didn't care about the overall number of 
connections, because now so much is synchronizing on the global 

Anyway, thanks for the help, everyone. Both of my original problems seem to be  
well on their way to being non-problems!

Next stop, cookies...

On Thursday March 20 2003 23:33, Michael Becke wrote:

> The problem, as other have been hinting at, is that connections never
> get destroyed.  By default, a max of two connections are created per
> HostConfiguration.  If you are never connecting to the same host more
> than once this is a bit of a problem.  The
> MultiThreadedHttpConnectionManager was designed to reuse connections
> for a small number of hosts.  So as you have guessed the connection
> manager will continue to create connections to new hosts and will never
> reclaim the old ones.  We have a couple of options for fixing this,
> here are a few:
> - create a cap on the max number of connections that can be created.
> once reached unused connections will be reclaimed
> - implement some kind of connection cache/timeout.  only connections
> that have been used in the last X milliseconds will be kept
> - implement a new type of connection manager that better fits this kind
> of process.  in particular it would focus less on connections per host,
> but more on total consecutive connections.  in general we could
> introduce a whole new set of connection managers they are optimized for
> different use scenarios
> These are just a few ideas.  What do others think?
> Mike
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org For additional
> commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

View raw message