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

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Thu, 13 Dec 2012 17:10:55 -0700

On 12/13/2012 03:49 PM, Eliezer Croitoru wrote:

> Since I am using basic squid process I assumed that the logic is that
> all workers use the same ufs

I wish it were true, but I am afraid your assumption is incorrect. I
would not call SMP Squid "basic", especially if caching is enabled. You
are using an advanced feature, with many caveats. Please see "What can
workers share?" at http://wiki.squid-cache.org/Features/SmpScale

> whihc is in this case is only one.

I am not sure whether you mean that are using one worker or one ufs
cache_dir in your squid.conf. If you have just one worker, then this is
not SMP Squid. If you have the same cache_dir line for all workers, then
your configuration is not currently supported: If you use ufs caching
with SMP Squid, then you have to give each worker a dedicated cache (and
those caches will not be in sync).

HTH,

Alex.

> On 12/14/2012 12:42 AM, Alex Rousskov wrote:
>> 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 Fri Dec 14 2012 - 00:10:58 MST

This archive was generated by hypermail 2.2.0 : Fri Dec 14 2012 - 12:00:10 MST