Thanks Dormando, I think you've almost certainly hit the nail on the head, many thanks
Roger On Sep 2, 10:34 am, dormando <[email protected]> wrote: > Willing to bet your clock was off? And/or it adjusted while you were > setting some values. > > > > On Wed, 2 Sep 2009, roger.moffatt wrote: > > > I have been completely stumped by this one. > > > I've had a windows install of memcached (1.2.6) running for months > > without incident in Amazon's compute cloud. Yesterday the server went > > AWOL and I had to instantiate a new server with Amazon. The image was > > fresh and everything came back as expected. Except for memcache which > > started refusing to store objects with a far distant expiry time (eg > > 12 hours in the future). I would write an object in, get no failure on > > the write, but the read immediately afterwards was returning null. > > > The only difference between the old server and the new one was that > > the new one was a slower cpu than the original (in Amazon terms, a > > m1.small instance rather than a c1.medium). > > > This affected every script that was using the cache to store objects > > with expiry times set. I'm using the CPAN memcached modules under > > mod_perl FYI. The scripts that were affected run on a different > > physical server. > > > As soon as I shortened the expiry time from 12 hours to 4 hours, it > > all started working again as before. This was repeatable and the > > system was in this state for an hour or more and I then gave up and > > went to bed. > > > Now that was some 9 hours ago. Presently I can raise the expiry time > > to 12 hours and the system works as expected. > > > I appreciate there are a lot of variables here, but can anyone think > > of anything obvious that could cause this? For example, the fact that > > the new server was physically different from the original one and was > > just running the same virtual image? OK that's beyond the scope of > > this group, but from a memcached perspective, is there anything I > > should be aware when using expiry? > > > Many Thanks > > Roger
