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
signature.asc
Description: Detta är en digitalt signerad meddelandedel
