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@xxxxxxxx> wrote: >> On Sat, Feb 15, 2014 at 1:46 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> 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
