On 08/27/2012 03:29 AM, Alexander Komyagin wrote: > Hi! My setup is Squid 3.2.1 + C-ICAP Antivirus. > > I noticed that in simulated production setup (e.g. 1200 http requests > per sec) there are dozens connections established from squid to c-icap > server, and even after the last client request timeouts, these > connections are still opened/opening. > > tcp 0 0 127.0.0.1:1344 127.0.0.1:51352 ESTABLISHED > tcp 722 0 127.0.0.1:1344 127.0.0.1:51500 ESTABLISHED > tcp 0 0 127.0.0.1:51374 127.0.0.1:1344 ESTABLISHED > ...
> Is this the intended behavior? ICAP connections are maintained separately from HTTP client connections and may be persistent. If you have N or more concurrent HTTP requests that need adaptation, it is likely that you will have N or more concurrent ICAP connections. Some or all of those connections will outlast the last HTTP client. The same is true for the HTTP server connections. In summary, there are at least three mostly independent pools of possibly persistent connections: HTTP client-side, HTTP server-side, and ICAP. There are squid.conf options to control how long an idle persistent connection is being kept in the pool. > Also there are a lot of "BUG: Orphaned connection" messages in my > cache.log under those conditions. I found out that they are caused by > Xaction destruction after client request timeout, getting > noteInitiatorAborted() before connection is established in the > corresponding ConnOpener job. I temporarily fixed that by notifying > ConnOpener (if any) in the Xaction::swanSong(). Please consider opening a bug report and/or submitting a patch fixing the problem. IIRC, Amos has mentioned that he left the BUG message their to collect all buggy cases that he could not identify through code analysis. I recall seeing these BUG messages as well, but I do not remember whether they were caused by the same sequence of events. Thank you, Alex.
