mån 2006-06-26 klockan 11:31 +0800 skrev Steven Wilton:
> Hmm, I'm not sure the above stack will ever happen. storeAbort is called
> from 2 places:
>
> storeSwapOut -> storeAbort
>
> storeClientUnregister -> CheckQuickAbort -> storeAbort
This one was the one I was thinking about..
> Both these functions (storeSwapOut and storeClientUnregister) call
> storeSwapOutMaintainMemObject first, which will call storeResumeRead.
Yes.. have come to the same conclusion.
But there is one more thing to consider which was overlooked initially:
Timeouts set by commSetTimeout().
squid.conf parameters:
lifetime_timeout
read_timeout
write_timeout
http.c use
In http.c httpTimeout() is registered as timeout handler, which simply
registers an error with fwdFail() and closes the socket.. and this is
the cause to the problems I think. But I haven't really verified by
making a test case (only reading code).
> Sorry if you've moved past this, but I like to know why a problem is
> occurring just as much as knowing what actually fixed the problem. I would
> imagine that our squids would crash constantly if client aborts could
> trigger this condition.
You are most welcome to verify the cause.
I have already hardened the defer code in 2.6 eliminating any
possibility of these windows, but it would be good to know for sure what
the cause was.
Regards
Henrik
This archive was generated by hypermail pre-2.1.9 : Fri Jun 30 2006 - 12:00:02 MDT