On 03/05/2014 10:51 AM, Niki Gorchilov wrote: > On Wed, Mar 5, 2014 at 6:59 PM, Niki Gorchilov <niki@xxxxxxxxxxxxx> wrote: >> Running a rock store experiment with SMP Squid 3.HEAD rev 13295 on 750 >> mbps of HTTP traffic. >> >> There're few cache.log errors and warnings that aren't clear enough >> for me. What triggers them, Squid bugs and/or invalid input, depending on the specific error and/or transaction. IMO, Squid should report these differently so that there are fewer questions/concerns about them, but there is currently no consensus regarding the best approach (or even regarding the existence of the systemic reporting/debugging problem itself!). Today, in most of these cases, the only way to know for sure what happened and what the exact effects are is to dive into detailed debugging logs (and even that might not be enough in corner cases). Monitoring access.log for errors may be helpful, but does not allow you to tie cache.log errors to access.log errors in most cases. >> and how do they affect the corresponding >> request that provoked them? >> WARNING: Ignoring malformed cache entry >> WARNING: swapfile header inconsistent with available data >> WARNING: 10 swapin MD5 mismatches >> Could not parse headers from on disk object >> clientProcessHit: Vary object loop! >> varyEvaluateMatch: Oops. Not a Vary object on second attempt, >> 'http://www.shaadi.com/' 'accept-encoding="gzip,deflate,sdch"' >> clientIfRangeMatch: Weak ETags are not allowed in If-Range: >> "68390-1391166396000" ? "68390-1391166396000" >> fqdncacheParse: No PTR record for '77.87.212.52' > > One more error: > idnsGrokReply: Malformed DNS response > >> My main concern is if any one of the above actually breaks the >> corresponding request? In most cases, these problems are not fatal to the request, except that some DNS errors may prevent Squid from forwarding the request, of course. And yes, I know that the above does not fully answer your questions, but that is the best answer I personally can offer at this time. HTH, Alex.
