And one more. It might be this patch which solved the issue
--- src/http.cc 2008-04-01 13:54:38.000000000 +0200
+++ src/http.cc 2008-04-21 19:11:47.000000000 +0200
@@ -1200,7 +1200,7 @@
void
HttpStateData::maybeReadVirginBody()
{
- int read_sz = replyBodySpace(readBuf->spaceSize());
+ int read_sz = replyBodySpace(readBuf->potentialSpaceSize());
debugs(11,9, HERE << (flags.do_next_read ? "may" : "wont") <<
" read up to " << read_sz << " bytes from FD " << fd);
spaceSize will only return the size left from initial size. This will result
in read_sz<2 and return some lines down in http.cc.
PotentialSpaceSize will return max_capacity - terminatedSize which seems
more logical.
Regards,
Axel Westerhold
DTS Systeme GmbH
> Ok,
>
> Did some additional checks,
>
> It should be
>
>
> --- src/http.cc 2008-04-01 13:54:38.000000000 +0200
> +++ src/http.cc 2008-04-21 16:42:19.000000000 +0200
> @@ -75,7 +75,7 @@
> surrogateNoStore = false;
> fd = fwd->server_fd;
> readBuf = new MemBuf;
> - readBuf->init(4096, SQUID_TCP_SO_RCVBUF);
> + readBuf->init( SQUID_TCP_SO_RCVBUF, SQUID_TCP_SO_RCVBUF);
> orig_request = HTTPMSGLOCK(fwd->request);
>
> if (fwd->servers)
>
> Which is btw. the coding used in ICAP where SQUID_TCP_SO_RCVBUF = 16384
>
> Regards,
> Axel
>
>
>> Hi there,
>>
>> I ran, or better a customer ran into a problem today which sounded like this
>> bug.
>>
>> http://www.squid-cache.org/bugs/show_bug.cgi?id=2001
>>
>>
>> So I applied the attached patch to squid-3.0.STABLE4 and did a quick test.
>> Still the same problem. By cache.log looks like this
>>
>>
>> ...
>> comm_read_try: FD 16, size 4094, retval 2896, errno 0
>> ...
>> HttpMsg::parse: failed to find end of headers (eof: 0)
>> ...
>> http.cc(1050) needs more at 2896
>> http.cc(1206) may read up to 1199 bytes from FD 16
>> ...
>> comm_select(): got FD 16 events=1 monitoring=19 F->read_handler=1
>> F->write_handler=0
>> comm_select(): Calling read handler on FD 16
>> comm_read_try: FD 16, size 1198, retval 1198, errno 0
>> ...
>> HttpMsg::parse: failed to find end of headers (eof: 0)
>> ...
>> http.cc(1050) needs more at 4094
>> http.cc(1206) may read up to 1 bytes from FD 16
>> ...
>> comm_select(): got FD 16 events=1 monitoring=19 F->read_handler=0
>> F->write_handler=0
>> comm_select(): no read handler for FD 16
>>
>> and so on and so on. So I checked the coding in http.cc and changed it as
>> follows.
>>
>> --- src/http.cc 2008-04-01 13:54:38.000000000 +0200
>> +++ src/http.cc 2008-04-21 16:42:19.000000000 +0200
>> @@ -75,7 +75,7 @@
>> surrogateNoStore = false;
>> fd = fwd->server_fd;
>> readBuf = new MemBuf;
>> - readBuf->init(4096, SQUID_TCP_SO_RCVBUF);
>> + readBuf->init(16384, SQUID_TCP_SO_RCVBUF);
>> orig_request = HTTPMSGLOCK(fwd->request);
>>
>> if (fwd->servers)
>>
>>
>>
>> Now it works but I am not sure if a.) this is a good solution and b.) a
>> stable
>> one :-).
>>
>> Maybe someone with more knowledge can do a check.
>>
>> Regards,
>> Axel Westerhold
>> DTS Systeme GmbH
>>
>
