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? Best, Niki
