> I have been using HTTrack alongside an Apache Tomcat4 web-
> server to generate the static portions of my web-site 
(with 
> great success - fantastic product!). I have found however 
> that under moderate load occasionally the web-server 
> process will stall (and stop serving) due to a number of 
> TCP connections  entering the CLOSE_WAIT state.  The only 
> way to release these is by restarting the web-server.  I 
am 
> a little confused as to which application might be 
causing 
> this issue (Tomcat or HTTrack).  I have a feeling it 
might 
> be HTTrack occasionally failing to call the final close
(), 
> however I might be wrong.

According to various network folks,

"CLOSE_WAIT is the state a TCP connection enters when the 
remote half has sent a FIN and now the local TCP is waiting 
for the local application to call close().  There is no 
timer running for the CLOSE_WAIT state - it will stay there 
until the app calls close() (perhaps shutdown) or the app 
terminates."

I will recheck the way httrack handles closes, but I doubt 
this is a missing close problem (httrack would crash very 
quickly, as more that 64 sockets can not be opened 
simultaneously). I could also issue a shutdown() before the 
close(), but this tend to cause problems on some buggy 
gateways.

httrack: FIN -> :server
(httrack called close())

httrack: ACK <- :server
(the server kernel detected the close)

--> here the server is in CLOSE_WAIT state

httrack: FIN <- :server
(the server application called () close and confirmed by 
sending a FIN)