Search squid archive

RE: storeurl_rewriter and "URL mismatch" log entries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This issue I'm seeing, where the original fetch url somehow gets into
the cache even though storeurl_rewriter is running and should be
normalizing it and caching only the normalized url...this seems to be
directly related to me also getting "TCP_SWAPFAIL_MISS" errors in my
access log.  

A request comes in, gets a TCP_MISS.  I thought that it then caches the
normalized url.  But then the next request for this same url gets a
TCP_SWAPFAIL_MISS.  After that, it gets TCP_HITs.  The TCP_SWAPFAIL_MISS
must be causing it to cache the original url.

Does this added info mean anything to anyone?  I'm trying to research
what causes the TCP_SWAPFAIL_MISS now and see if I can find anything.

Thanks so much!


-----Original Message-----
From: Kathleen M Kelly [mailto:kmkelly@xxxxxxxxxxxxx] 
Sent: Tuesday, November 17, 2009 5:14 PM
To: squid-users@xxxxxxxxxxxxxxx
Subject:  storeurl_rewriter and "URL mismatch" log entries

Hello,

I have a squid application where a storeurl_rewriter program is needed
to normalize incoming fetch urls into the same url.  I am running
squid-2.7_9, and have a storeurl_rewriter program that gets launched at
squid startup.  In my config file, I set storeurl_rewrite_children to
100, and only allow http requests to come through (using the
storeurl_access allow proto HTTP setting, so any
cache_object://localhost requests will be ignored).

The problem I am having is I keep getting cache.log entries that look
like "storeClientReadHeader: URL mismatch", comparing the incoming fetch
url with my normalized url.  I am getting thousands of these errors an
hour.  I was sure to clear out the squid cache as I launched my new
storeurl_rewriter program, so I don't understand how the cache has any
of the original fetch urls in it at all to be causing this URL mismatch.
I was getting warnings about not enough storeurl_rewriter programs
running, which was when I bumped it up to 100.  I was also having an
issue where logs showed that when the cache_object://localhost requests
came through, my program shut down, which was why I added the access
setting.  I don't see either of these warnings in the logs anymore, yet
still see tons of URL mismatch errors.

Does anyone have any ideas on this?  

Just to clarify a bit more...suppose a fetch url looks like
http://www.fetchme.com/123456, but it should then go through my
storeurl_rewriter program where it will be turned into
http://www.normalized.com/123456, and this is what should be used to
fetch and then cache.  My assumption is that every fetch request goes
through storeurl_rewriter, so how is it that I would be seeing so many
log entries like "storeClientReadHeader: URL mismatch
{http://www.normalized.com/123456} != {http://www.fetchme.com/123456}?
Is there some case where a fetch request does not go through
storeurl_rewriter?  If it was busy, I think I would be seeing a log
warning saying so, which I am not since I bumped children to 100.


Thanks so much,

Kathleen 


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux