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 >
