RE: [squid-users] Problem with siblings running on different http ports

From: Lu, Roy <rlu_at_FACorelogic.com>
Date: Fri, 26 Jun 2009 11:21:00 -0700

Here is some more information on my previous question. The
configuration, test requests and logs are listed below.

Configuration on squid A (http port 7129):
------------------------------------
http_port 7129 accel defaultsite=vmdevcagpcna01.firstamdata.net

acl ACLGPLSites dstdomain vmdevcagpcna01.firstamdata.net
acl ACLSquidPeers src 192.168.54.65

http_access allow ACLGPLSites
icp_access allow ACLSquidPeers
#miss_access allow ACLSquidPeers

# origin app server is vmdevcagpcna01 (192.168.54.64:7533)
cache_peer vmdevcagpcna01.firstamdata.net parent 7533 0 no-query
originserver name=OriginGPLServer
cache_peer 192.168.54.65 sibling 7130 7230 name=GPLCache2 proxy-only

cache_peer_access OriginGPLServer allow ACLGPLSites
cache_peer_access GPLCache2 allow ACLGPLSites

icp_port 7229

# allow purge method from localhost
acl PURGE method purge
acl localhost src 192.168.54.65
http_access allow purge localhost
http_access deny purge
-----------------------------------

Configuration on squid B (http port 7130):
------------------------------------
http_port 7130 accel defaultsite=vmdevcagpcna01.firstamdata.net

acl ACLGPLSites dstdomain vmdevcagpcna01.firstamdata.net
acl ACLSquidPeers src 192.168.54.65

http_access allow ACLGPLSites
icp_access allow ACLSquidPeers
#miss_access allow ACLSquidPeers

# origin app server is vmdevcagpcna01 (192.168.54.64:7533)
cache_peer vmdevcagpcna01.firstamdata.net parent 7533 0 no-query
originserver name=OriginGPLServer
cache_peer 192.168.54.65 sibling 7129 7229 name=GPLCache1 proxy-only

cache_peer_access OriginGPLServer allow ACLGPLSites
cache_peer_access GPLCache1 allow ACLGPLSites

icp_port 7230

# allow purge method from localhost
acl PURGE method purge
acl localhost src 192.168.54.65
http_access allow purge localhost
http_access deny purge
------------------------------------

The sequence of requests that I sent was:
------------------------------------
./squidclient -h 192.168.54.65 -p 7129 -m HEAD -H "Cache-Control:
only-if-cached\n"
"http://vmdevcagpcna01.firstamdata.net/gis/v1.6.3/wms?REQUEST=GetMap&SER
VICE=WMS&VERSION=1.1.1&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT=TRU
E&SRS=EPSG:4326&WIDTH=256&HEIGHT=256&reaspect=false&LAYERS=GPL:property_
layer&QuadKey=0230132002300312230"

./squidclient -h 192.168.54.65 -p 7130 -m HEAD -H "Cache-Control:
only-if-cached\n"
"http://vmdevcagpcna01.firstamdata.net/gis/v1.6.3/wms?REQUEST=GetMap&SER
VICE=WMS&VERSION=1.1.1&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT=TRU
E&SRS=EPSG:4326&WIDTH=256&HEIGHT=256&reaspect=false&LAYERS=GPL:property_
layer&QuadKey=0230132002300312230"

./squidclient -h 192.168.54.65 -p 7130
"http://vmdevcagpcna01.firstamdata.net/gis/v1.6.3/wms?REQUEST=GetMap&SER
VICE=WMS&VERSION=1.1.1&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT=TRU
E&SRS=EPSG:4326&WIDTH=256&HEIGHT=256&reaspect=false&LAYERS=GPL:property_
layer&QuadKey=0230132002300312230"
------------------------------------

Access.log from Squid A:
------------------------------------
1246040022.545 0 192.168.54.65 TCP_MEM_HIT/200 274 HEAD
http://vmdevcagpcna01.firstamdata.net:7129/gis/v1.6.3/wms?REQUEST=GetMap
&SERVICE=WMS&VERSION=1.1.1&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT
=TRUE&SRS=EPSG:4326&WIDTH=256&HEIGHT=256&reaspect=false&LAYERS=GPL:prope
rty_layer&QuadKey=0230132002300312230 - NONE/-
application/vnd.ogc.se_xml
1246040041.305 0 192.168.54.65 UDP_MISS/000 274 ICP_QUERY
http://vmdevcagpcna01.firstamdata.net:7130/gis/v1.6.3/wms?REQUEST=GetMap
&SERVICE=WMS&VERSION=1.1.1&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT
=TRUE&SRS=EPSG:4326&WIDTH=256&HEIGHT=256&reaspect=false&LAYERS=GPL:prope
rty_layer&QuadKey=0230132002300312230 - NONE/- -
-------------------------------------

Access.log from Squid B:
-------------------------------------
1246040028.217 0 192.168.54.65 TCP_MISS/504 290 HEAD
http://vmdevcagpcna01.firstamdata.net:7130/gis/v1.6.3/wms?REQUEST=GetMap
&SERVICE=WMS&VERSION=1.1.1&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT
=TRUE&SRS=EPSG:4326&WIDTH=256&HEIGHT=256&reaspect=false&LAYERS=GPL:prope
rty_layer&QuadKey=0230132002300312230 - NONE/- text/html
1246040041.391 86 192.168.54.65 TCP_MISS/200 5762 GET
http://vmdevcagpcna01.firstamdata.net:7130/gis/v1.6.3/wms?REQUEST=GetMap
&SERVICE=WMS&VERSION=1.1.1&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT
=TRUE&SRS=EPSG:4326&WIDTH=256&HEIGHT=256&reaspect=false&LAYERS=GPL:prope
rty_layer&QuadKey=0230132002300312230 - FIRST_UP_PARENT/OriginGPLServer
image/png
-------------------------------------

As you can see that, A has the object(TCP_MEM_HIT), while B does
not(TCP_MISS). But when a request for the object is sent to B, A gets a
UDP_MISS with a URL having squid B's port number 7130 in it. I don't
understand why.

Thanks!
Roy

-----Original Message-----
From: Lu, Roy [mailto:rlu_at_FACorelogic.com]
Sent: Friday, June 26, 2009 10:28 AM
To: squid-users_at_squid-cache.org
Subject: [squid-users] Problem with siblings running on different http
ports

Dear list,

I have two squid sibling caches in accelerator mode with different http
ports (squid A port 3128 and squid B 3129). Both point to the same back
end origin server. When i used the squidclient to test them, I made sure
squid A has a requested object in cache(TCP_HIT), while squid B does
not(TCP_MISS).
Now when I send a request to B, I can see a message in A's access log
with UDP_MISS status, but the ICP_QUERY url contains B's http port 3129.
So the result is B goes to the backend sever to get the object, instead
of from A.

Why does the ICP_QUERY have the requesting silbling's http port?

Thanks,
Roy
************************************************************************
******************
This message may contain confidential or proprietary information
intended only for the use of the
addressee(s) named above or may contain information that is legally
privileged. If you are
not the intended addressee, or the person responsible for delivering it
to the intended addressee,
you are hereby notified that reading, disseminating, distributing or
copying this message is strictly
prohibited. If you have received this message by mistake, please
immediately notify us by
replying to the message and delete the original message and any copies
immediately thereafter.

Thank you.
************************************************************************
******************
FACLD
Received on Fri Jun 26 2009 - 18:21:10 MDT

This archive was generated by hypermail 2.2.0 : Sat Jun 27 2009 - 12:00:03 MDT