Closed (fixed)
Project:
Memcache Storage
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Reporter:
Created:
24 Sep 2013 at 16:26 UTC
Updated:
8 Dec 2013 at 13:40 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
spleshkaHi Markus,
Did you looked into the MS code? :) Please, see this, and pay your attension at this lines:
So the timestamp is converted to the memcached TTL format.
By the way, if timestamp is passed without substruct of REQUEST_TIME, memcached will consider it as a unix timestamp, and item will be expired properly anyway.
Comment #2
mkalkbrennerCreated a patch to solve this issue.
Comment #3
spleshkaOh, I understand what do you mean. But memcached will not fetch expired items from its pool. So no need to check already expired items in validation, because if current timestamp is greater then cache item expiration timestamp, memcached will return FALSE instead of item.
Comment #4
spleshkaIf you dont trust me, then just execute following code:
Comment #5
mkalkbrennerDuring posting #2 I was not aware of that you already posted comment #1 => Race Condition ;-)
Your snippet works.
Comment #6
spleshkaSo no more problems with cache invalidation? Please, feel free to send me any feedbacks about Memcache Storage.
Comment #7
mkalkbrennerIndeed, we have some strange problems. Basically it seems that the invalidation is not 100% reliable:
drush updb; drush cc allwe sometimes face some "strange behaviors" of the site until we restart the memcached.That's why I started to search through your module to find a case where a cache entry is not invalidated correctly.
Comment #8
spleshkaOh.. Are there any possibility to debug this together? I want to find the problem, because till your issue I never heard about problems with expiration.
Comment #9
mkalkbrennerI'm just talking to my colleagues how we could reproduce the errors "reliable" to have the chance to debug it.
Meanwhile some details about our setup. We're running drupal multisite setup deployed on multiple servers. memcached runs on two servers. This is one of the configurations:
Comment #10
spleshkaCould you temporary disable one of the memcached servers? I mean leave only one server and try to run
drush cc allagain and see if problem remain. May be problem in network communication.Comment #11
spleshkaBy the way, for you set up is better to enable compression, because you use tcp instead of sockets, so you loose some time on the network delivery. And if the data will be smaller - the delivery should be faster.
Comment #12
mkalkbrennerThanks for your hint regarding the compression.
We'll do some intensive tests including the shutdown of one memcached next week during low traffic hours.
Meanwhile we try to reproduce the various errors in the development and the staging environment. I'll keep you informed ...
Comment #13
spleshkaGreat, looking forward for the tests results.
Comment #14
mkalkbrennerWe did a *lot* of tests and tuned our memcached installation. But currently we're only running one memcached server. So far we're not able to reproduce bugs, but we'll wait another week if an error occurs.
After that, we'll probably re-enable the memcache distribution on multiple servers and do some more tests.
One thing we noticed is the way the drupal core update module works. It's possible to access the "cache_update" using cache_get, cache_set and cache_clear_all, but internally the module uses hard coded sql to access the cache_update table. Therefore we added
$conf['cache_class_cache_update'] = 'DrupalDatabaseCache';to avoid possible bugs.Comment #15
spleshkaThanks a lot for a tests! So I see that currently there are no issues with cache invalidation. But for cache_update I think it would be nice to have a couple notes in the README about such hardcoded behavior.
Comment #15.0
spleshkafixed typo
Comment #16
spleshkaI've commited and pushed the data about cache_update in the README. I think that issue is solved for now, am I right?