Re: [BUG] PURGE method with SMP dosnt play nice. 3.2 3.3 and trunk.

On 12/13/2012 01:15 PM, Eliezer Croitoru wrote:
> While testing my storeID I found a small bug with SMP and memory_cache
> While squid PURGE methods works fine with one basic process it will not
> play well with SMP.
>
> The test case is with and without storeID.
> 1. fetch url of a jpg img. result(tcp_miss)
> 2. fetch again to make sure it's served from cache. result (tcp_hit)
> 3. check the file on disk. result: exists on disk (the only file in cache)
> 4. squidclient -m PURGE url result:no errors
> 5. check logs. result: a purge was made
> 6. check disk object (UFS) result: dosnt exists.
> 7. fetch the url.
> result in logs:
> 1355429182.213 5 192.168.10.100 TCP_MEM_HIT/200 5219 GET
> http://i1.ytimg.com/vi/H-0OuRVCAK8/default.jpg - HIER_NONE/- image/jpeg
>
> The next test was to change the settings into:
> maximum_object_size_in_memory 1 Bytes
>
> Which means no object will be cached in memory.
>
> Then I did all the tests and now the result is:
> 1355429555.386 27 192.168.10.100 TCP_MISS/200 5220 GET
> http://i1.ytimg.com/vi/H-0OuRVCAK8/default.jpg -
> HIER_DIRECT/74.125.132.100 image
>
>
> So the bug is in SMP with purge in mem_cache only!
>
> I will file a bug in the Bugzilla.
>
> This mail is just to make sure I am understood about the situation.

Are you using a shared memory cache? If yes, please file a bug report.
You may want to add ${process_name} to your access.log line to show
which worker all these GET and PURGE requests went to.

Please note that ufs storage is not SMP-aware so the fact that the file
disappeared from disk on PURGE in your test case was just an accident.
The file will stay on disk if the worker receiving a PURGE request is
different from the worker that cached the file.

Thank you,

Alex.
Received on Thu Dec 13 2012 - 22:42:14 MST