Re: ICAP connections under heavy loads

Thanks, Alex. My bad. Let me clarify the issue. I have Squid 3.2.1 (transparent) + c-icap (e.g. clamav). Currently I'm testing performance of this setup with httperf tool. When the number of client http requests is so big that c-icap becomes overloaded, some connections from Squid to icap are

Jenkins build is back to normal : 3.HEAD-amd64-CentOS-5.3 #2033

See http://build.squid-cache.org/job/3.HEAD-amd64-CentOS-5.3/2033/changes

Build failed in Jenkins: 3.HEAD-amd64-FreeBSD-7.2 #1554

See http://build.squid-cache.org/job/3.HEAD-amd64-FreeBSD-7.2/1554/ -- Started by upstream project 3.HEAD-amd64-CentOS-5.3 build number 2033 Building remotely on east in workspace http://build.squid-cache.org/job/3.HEAD-amd64-FreeBSD-7.2/ws/ Cleaning

Build failed in Jenkins: 3.HEAD-amd64-opensuse #188

See http://build.squid-cache.org/job/3.HEAD-amd64-opensuse/188/changes Changes: [Amos Jeffries] Fix 'error: continue statement not within a loop' [Amos Jeffries] Bug 3609: several RADIUS helper improvements [Amos Jeffries] Regression: login=PASS send no credentials when none available.

Build failed in Jenkins: 3.HEAD-ppc-MacOS-Leopard #30

See http://build.squid-cache.org/job/3.HEAD-ppc-MacOS-Leopard/30/changes Changes: [Amos Jeffries] Fix 'error: continue statement not within a loop' [Amos Jeffries] Bug 3609: several RADIUS helper improvements [Amos Jeffries] Regression: login=PASS send no credentials when none available.

Re: ICAP connections under heavy loads

On 08/29/2012 04:45 AM, Alexander Komyagin wrote: I have Squid 3.2.1 (transparent) + c-icap (e.g. clamav). Currently I'm testing performance of this setup with httperf tool. When the number of client http requests is so big that c-icap becomes overloaded, some connections from Squid to icap

[PATCH] Do not reuse persistent connections for PUTs

Hello, I saw bogus ERR_ZERO_SIZE_OBJECT responses while testing Squid v3.1, but the same problem ought to be present in v3.2 as well. A compliant proxy may retry PUTs, but Squid lacks the [rather complicated] code required to protect the PUT request body from being nibbled during the first

Re: [PATCH] Do not reuse persistent connections for PUTs

ons 2012-08-29 klockan 12:42 -0600 skrev Alex Rousskov: Hello, I saw bogus ERR_ZERO_SIZE_OBJECT responses while testing Squid v3.1, but the same problem ought to be present in v3.2 as well. A compliant proxy may retry PUTs, but Squid lacks the [rather complicated] code required to

Re: [PATCH] Do not reuse persistent connections for PUTs

ons 2012-08-29 klockan 22:20 +0200 skrev Henrik Nordström: ons 2012-08-29 klockan 12:42 -0600 skrev Alex Rousskov: Hello, I saw bogus ERR_ZERO_SIZE_OBJECT responses while testing Squid v3.1, but the same problem ought to be present in v3.2 as well. A compliant proxy may retry

Re: [PATCH] Do not reuse persistent connections for PUTs

On 08/29/2012 02:32 PM, Henrik Nordström wrote: ons 2012-08-29 klockan 22:20 +0200 skrev Henrik Nordström: ons 2012-08-29 klockan 12:42 -0600 skrev Alex Rousskov: I saw bogus ERR_ZERO_SIZE_OBJECT responses while testing Squid v3.1, but the same problem ought to be present in v3.2 as well.

Build failed in Jenkins: 3.2-matrix » east #261

See http://build.squid-cache.org/job/3.2-matrix/./label=east/261/ -- Started by upstream project 3.2-matrix build number 261 Building remotely on east in workspace http://build.squid-cache.org/job/3.2-matrix/./label=east/ws/ Cleaning workspace... $ bzr

Build failed in Jenkins: 3.2-matrix » opensuse-x64 #261

See http://build.squid-cache.org/job/3.2-matrix/./label=opensuse-x64/261/ -- [...truncated 6927 lines...] Testing ../../src/FileMap.h ...Ok. Testing ../../src/ConfigParser.h ...Ok. Testing ../../src/client_side.h ...Ok. Testing ../../src/StoreMeta.h ...Ok.

Re: [PATCH] Do not reuse persistent connections for PUTs

ons 2012-08-29 klockan 15:32 -0600 skrev Alex Rousskov: Today, we have a choice: A. Fail some PUTs. Close fewer pconns (current code). B. Handle all PUTs. Open more connections (patched code). If this patch is accepted, performance bug 3398 will resurface. Henrik, do you think