Re: 2 fixes for the squid icap implementation

Hi Graeme,
  I did not verified the problems but looks that the problems exist.

About the first patch I am proposing a somehow different approach.
When squid-icap takes a 204 response immediately releases the connection
and put it to connections poll so it can be used for other icap requests.
The icap connection's file descriptor is no more related to the
IcapStateData structure and only we have to free this structure when we
have all data from the http server.
The patch is attached if you want to test it.
I must verify it and correct it before apply it to the cvs.
If it causes problems I will proceed with your patch.

About the second patch if there is not any problem I want to test it
more and if it is possible to move most of its code to the icap_*.c
files. This will save as time during merging with main branch..

Regards,
   Christos

Graeme Bisset wrote:
> Hi,
>
> Could someone add the 2 attached patches to the squid icap client?
>
> Here's a description of what they fix...
>
> 15minutefix.patch
> =================
> I noticed that if an icap server replied with a 204 response, the
> download would continue without being forwarded to icap but it would
> then abort after 15 minutes. This was because the read timeout on the
> icap connection wasn't being cancelled. This fix cancels the timeout
> which avoids the aborted downloads.
>
> squidcrashfix.patch
> ===================
> A fix that I submitted some time ago (squidgrowthfix.patch) caused squid
> to crash under heavy load. This was because the deferred read check I
> added relied on the store entry object being present but didn't lock it.
> Under heavy load the store entry was sometimes freed before the defer
> read check which caused squid to crash. This patch maintains a lock on
> the store entry object and also has some other code to make sure the
> store entry object is unlocked and freed when it is no longer required.
>
> Thanks,
>
> Graeme