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

On 29/01/2014 2:04 a.m., Niki Gorchilov wrote:
> 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

Did you leave sufficient time after doing this to ensure that the -z
operation was completed successfully and all the "squid -z" spawned
processes stopped?

> 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

Step 4 operation is blocked by the "reload_into_ims on" config directive
which turns these force-reload (Cache-Control:no-cache) requests into
If-Modified-Since (IMS) requests.

Under correct protocol operation they should be TCP_MISS responses.

>
> 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?

I note that you are only waiting 5-10 seconds between teh refresh and
escape. While this may be long enough, does the trace show any
difference if you leave it for a much longer time such as 30 or 60 seconds?

Amos
Received on Wed Jan 29 2014 - 03:19:06 MST