On 12.09.2012 04:21, grant lowe wrote:
Ok. I changed the line to go to port 80, instead of port 3128. I read
that that is a better choice since this is a reverse proxy. Here's
the
line I changed:
cache_peer prdseoproxy02.corp.bbi.com sibling 80 3130
But I'm still having grief. Sending a song to the first sibling gives
a TCP_MISS. The other sibling gives a UDP_MISS. Sometimes I see this:
1347379698.716 0 10.2.12.185 TCP_MEM_HIT/200 583 GET
http://prdseoproxy02.corp.bbi.com/squid-internal-periodic/store_digest
- HIER_NONE/- application/cache-digest
A successful digest exchange.
But not always. Ready to pull my hair out!
Why are you so frustrated? you are telling us about success after
success and saying they are "wrong".
* IMPORTANT details: *_MISS is a ***WORKING*** test. No amount of
connectivity will make it work better. Storage and message headers are
the details to focus on to change them into HITs.
* your squid configuration earlier was accurate and should have been
working if the surrounding network (ie firewalls, routing, IP ranges
etc) was working in accordance with the squid.conf details provided.
* having things only work when you use port-80 as opposed to any other
port smells like firewall rules getting in the way to me.
* having forward proxy traffic (between the proxies is all
'forward'/proxy HTTP format messages) going to a reverse proxy is not
good. Works, but the reverse-proxy implicit assumptions can cause issues
with URLs.
* what do the failures *exactly* look like? what *exactly* were you
expecting to see?
Amos
On Mon, Sep 10, 2012 at 6:24 PM, Amos Jeffries wrote:
On 11.09.2012 13:15, grant lowe wrote:
The sibling is in the next rack and on the same network and VLAN.
It is
configured as a mirror to this one, the only thing being different
is the
IP address. They have the same parents, ports, etc. So it sounds
like I
should try the connection between the servers on port 3128?
Yes.
Amos
