> If nothing helps, send headers and relevant debugging info back to us.
I've solved some of the problem, but not all. Here is some debug data.
I experimented with an empty proxy. The requested URL was not in cache, but
it is on a very popular page, so I was sure it was on other caches of the
cluster.
1998/10/07 12:44:48| fwdStart: 'http://194.100.30.109/kuvat/ala2.gif'
1998/10/07 12:44:48| peerSelect: http://194.100.30.109/kuvat/ala2.gif
1998/10/07 12:44:48| peerSelectFoo: 'HEAD 194.100.30.109'
1998/10/07 12:44:48| peerSelectFoo: direct = DIRECT_MAYBE
1998/10/07 12:44:48| peerDigestLookup: peer themis.netti.fi
1998/10/07 12:44:48| peerDigestLookup: Usable!
1998/10/07 12:44:48| peerDigestLookup: OK to lookup peer themis.netti.fi
1998/10/07 12:44:48| cacheDigestHashKey: E8E18DE17147D3C66535B158427C4542 -(2129192)-> 28713 1293414 1051600 1873034
So far so good, it was found on themis.
1998/10/07 12:44:48| peerDigestLookup: peer mnemosyne.netti.fi
1998/10/07 12:44:48| peerDigestLookup: Usable!
1998/10/07 12:44:48| peerDigestLookup: OK to lookup peer mnemosyne.netti.fi
1998/10/07 12:44:48| cacheDigestHashKey: E8E18DE17147D3C66535B158427C4542 -(868896)-> 539617 257126 194840 646882
So far so good, it was found also on mnemosyne.
1998/10/07 12:44:48| neighborsDigestSelect: choices: 2 (0)
That makes two possibilities. I guess it's ok to have ichoice_count 0 here?
1998/10/07 12:44:48| peerNoteDigestLookup: peer <none>, lookup: LOOKUP_MISS
What is this? There are only two peers defined, why this row appears? Is it
standard or do I have a typo in my config file?
1998/10/07 12:44:48| peerSelectIcpPing: http://194.100.30.109/kuvat/ala2.gif
1998/10/07 12:44:48| peerSelectFoo: After peerSelectIcpPing.
This is OK too, I guess..
1998/10/07 12:44:48| whichPeer: from 0.0.0.0 port 0
1998/10/07 12:44:48| whichPeer: from 0.0.0.0 port 0
1998/10/07 12:44:48| whichPeer: from 0.0.0.0 port 0
1998/10/07 12:44:48| whichPeer: from 0.0.0.0 port 0
But then again, what is this?
1998/10/07 12:44:48| peerSelect: DIRECT/194.100.30.109
1998/10/07 12:44:48| peerSelectCallback: http://194.100.30.109/kuvat/ala2.gif
1998/10/07 12:44:48| fwdConnectStart: http://194.100.30.109/kuvat/ala2.gif
1998/10/07 12:44:48| fwdDispatch: FD 16: Fetching 'HEAD http://194.100.30.109/kuvat/ala2.gif'
1998/10/07 12:44:48| fwdUnregister: http://194.100.30.109/kuvat/ala2.gif
Finally Squid decided to fetch document directly from the source. I couldn't
get more debug data on where peerselect decided to work unexpectedly.
> P.S. Be sure each peer has a unique name. If several caches have the same
> name (RR DNS balancing and such), digests (and other things) may not work.
Of course.
So my problem seems to be in the peer selection algorithm rather than in
digests. Any ideas?
always_direct. never_direct, query_icmp and minimum_direct_hops are all
empty.
-- Teemu Peltonen Netti Finland sysadmin http://www.netti.fiReceived on Wed Oct 07 1998 - 02:49:43 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:42:21 MST