Hi all!
I'm experiencing a strange issue when delivering cached results from
rock store, that doesn't exist while using aufs with exactly the same
configuration.
In short, some random TCP_HIT responses never get delivered back to
the user. It happens quite often (say 10-20%) when the refresh logic
doesn't require contacting the origin server. As a result both Squid
and the browser enter into infinite waiting state, until the user
aborts the session by pressing ESC. Once the ESC is pressed and
browser drops the connection a TCP_HIT_ABORTED entry shows in
access.log.
Tested with my own builds of Squid 3.4.2 and 3.HEAD-BZR under Ubuntu
12.04.3 and Eliezer's 3.4.2 CentOS 6 build. No any difference - the
problem persists while using rock store, and disappears when switching
to aufs.
Managed to create a simple conf and usage scenario to reproduce the
problem easily.
===[squid.conf]===
http_port 3128
shutdown_lifetime 0 seconds
http_access allow all
cache allow all
# Test case only options!
# not used in production but easier to reproduce the issue
# by forcing cache delivery from disk instead of memory
# and avoid contacting the origin server
reload_into_ims on
cache_mem 0 MB
# rocks storage only - doens't work
# aufs torage only - works
cache_dir rock /squid_test_rock 100 max-size=31000
#cache_dir aufs /squid_test_aufs 100 16 16
===[eof]===
The simple steps to reproduce:
1. Empty store dir and recreate swap with -z
2. Start Squid with the above config
3. Open a new private browser session (or clear browser cache) and
request www.w3.org. Most of the 35+ requested items will get cached.
4. Once the page loads fully, request full reload Ctrl-Shift-R/Cmd-Shift-R
During this (and every next) reload few (1-3-5) random requests out of
all 35+ objects will enter into this strange state, until the user
aborts the connection.
Access.log excerpts:
rock: http://pastebin.com/QWTgqRTD
aufs: http://pastebin.com/0WGdHPP9
Pay attention to '===[]===' marks in the logs, marking user's actions.
Please help! Can you reproduce the problem or it's somehow related to
my environment?
Best,
Niki
Received on Tue Jan 28 2014 - 13:05:41 MST
This archive was generated by hypermail 2.2.0 : Wed Jan 29 2014 - 12:00:06 MST