I thought, that "0" means to never close down the _active_ (not all) connections.
>From documentation: "If the transfer to the client is not complete before this timeout expires, then Traffic Server closes the connection. The default value of 0 specifies that there is no timeout." >From my understanding TS will forcibly close the connection when timeout will be expired. In my case "0" is not a solution, because, even not active connections is still being present as current connections, and I can see it by "traffic_line -r proxy.node.current_client_connections", and this number is permanently increasing. On 10.01.2013 17:28, Leif Hedstrom wrote: > On 1/9/13 11:59 PM, Vladyslav Bachynskyi wrote: >> Hi, >> >> Sorry for so late reply. >> I need to keep that variable so large, because I'm using TS as a cache >> for Video on Demand content, and I don't want connection be closed >> during movie playing. > > > Maybe I misunderstood you. It sounded like the problem occurs when the > config is set to 0 ? That's why I'm wondering what is going on, > because "0" means to never close down those connections (in timeouts, > 0 means 'infinite'). > > If you solution to the problem is to set it to "0", then it makes sense. > > -- Leif > >> Thanks, >> >> >> On 03.01.2013 17:03, Leif Hedstrom 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? >>> >>> -- Leif >>> >
