[squid-users] Fwd: rock store: a bug or ...?

From: Niki Gorchilov <niki_at_gorchilov.com>
Date: Tue, 28 Jan 2014 15:04:54 +0200

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