On Thu, Jan 3, 2013 at 10:03 AM, Leif Hedstrom <[email protected]> wrote:
> On 1/3/13 12:36 AM, Vladyslav Bachynskyi wrote: > >> Hi, >> I've Found the root cause. >> I have had to many CLOSE_WAIT connections because I've set >> proxy.config.http.transaction_**active_timeout_in to 0. >> By changing this variable the issue has been solved. >> I thought, as such connections are not active, they should be fully >> closed even without transaction_active_timeout_in.**.. >> > > Hmmmm. That seems somewhat odd that it'd help. It'd be interesting to look > into why (that setting is necessary to keep at 0 for e.g. very large files > (streaming media for example, or YouTube proxy/caching). Or alternatively, > keep it very large (certainly much larger than 120s). What did you set it > to ? > > What is the problem having connections in CLOSE_WAIT anyways? The kernel > should clean that out after some time (like 120s or some such), no? > > CLOSE_WAIT connections are going to get re-cycled by the kernel. CLOSE_WAITs are due to the local application not performing a close on the file descriptor even after the remote side has sent a FIN to close out its side. The OP's close_wait output suggests ATS still thinks it can't close out the client side connection for some reason. Sridhar > -- Leif > >
