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
