hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: CRLF and Connection: close
Date Fri, 21 Mar 2003 04:33:15 GMT
> The second thing has to do with how Keep-alive connections behave. 
> This is a
> multi-threaded app, using MultiThreadedHttpConnectionManager. It works 
> great,
> however I don't get much benefit of the shared Connections, because 
> I'm not
> connecting to the same site more than once, generally. That's OK, the 
> problem
> I run into is that after running for not very long, I suddenly start 
> getting
> everything timing out. It's hard to really pinpoint the timing, giving 
> all the
> activity, and no thread identifiers in the log messages, but I think 
> what is
> happening is that the system is simply running out of file handles or
> system-level connections. A quick "netstat -n" shows a whole bunch of 
> open,
> TIME_WAIT, and other connections. It seems that the Connection Manager 
> is
> keeping them around for re-use, and following HTTP/1.1. One fix was to 
> send
> "Connection: close" as a RequestHeader, which really fixed things up, 
> but now
> I am running into sites that are not responding, and not timing out. 
> The log
> traces into ReadRawLine() and just sits there. I am still tracking 
> this down,
> I just wonder if anyone else has seen this also?

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


Mime
View raw message