On 17/02/2014 10:27 p.m., Nikolai Gorchilov wrote:
> Dear Amos,
>
> On Sat, Feb 15, 2014 at 3:12 PM, Nikolai Gorchilov <niki_at_x3me.net> wrote:
>> On Sat, Feb 15, 2014 at 1:46 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
>>
>> I'm trying to avoid the following scenario (excerpt from store.log):
>>
>> 1392406208.398 SWAPOUT 00 00000000 8C2B9C51268EFEEDEB33FB9EC53030A1
>> 200 1392406217 1382373187 1394998217 image/jpeg 21130/21130 GET
>> http://www.gnu.org/graphics/t-desktop-4-small.jpg
>> 1392406242.459 SWAPOUT 00 00000000 8C2B9C51268EFEEDEB33FB9EC53030A1
>> 200 1392406217 1382373187 1394998217 image/jpeg 21130/21130 GET
>> http://www.gnu.org/graphics/t-desktop-4-small.jpg
>>
>> First request was served by kid1. It fetched the object by
>> HIER_DIRECT, memory cached it, and stored it to it's storage (say
>> /S1).
>> Seconds later, the same request arrives to kid2. It retrieves the
>> object from shared memory (hierarchy code NONE), then swaps it out to
>> it's own storage (say /S2).
>>
>> The question is how to prevent kid2 from saving the duplicate object?
>> Is there any mechanism other then switching memory_cache_shared off?
>
> Can you recommend a solution regarding the above mentioned case?
Not at this point. Alex is the one to talk to about this.
Amos
Received on Mon Feb 17 2014 - 10:04:27 MST
This archive was generated by hypermail 2.2.0 : Mon Feb 17 2014 - 12:00:05 MST