Hello,
In features.module, you did an implementation of hook_flush_caches() that actually seems to call the "rebuild" operation on all features. I think this a really bad idea.
hook_flush_caches() gets called at each cron run, thus in order to get back cache table names and remove expired entries.
On some productions sites with quite high data volumetry, your implementation implies content types rebuild and *a lot* of non expired data flush, where the cron is arbitrary run by an external deamon depending on the box load, it can sometime get called every two minutes, which means that it invalidates Drupal cache for a lot of stuff every two minutes, this is not acceptable and causes a lot of cache miss that should not happen.
I'm not sure about this last statement, but it seems that the feature's content module support will wipe out all content module cache, which will wipe out all node's individual cache, which will then make the content caching mecanism totally useless.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | features-944882.patch | 1.49 KB | chrisns |
Comments
Comment #1
pounardI'm still not sure this really does wipe out content cache, but I think you should be aware that this hook will be called in non cache wipeout context, and it happens a lot.
Comment #2
hefox commentedSubscribe
I've been considering it would be nice to at least disable looking for updates during cache clear for performance and potential upgrade issues (had some issues when converting from exportables taxonomy intergration to features; had to delete the vocabularies that features created during cache clear (we run cc before updatedb).)
(It sounds like your content issues likely should be investigated; however I'd suggest using supercron or one of the other advanced cron modules to pick and choice what cron jobs run when. We only run full cron every 6 hours, but run other cron jobs sooner.)
Comment #3
chrisns commentedNOT A GENERAL PURPOSE FIX
we had the issue of deploying fields with features on our environment
in short you added a field that depends on a module, the field would get added to the content type before the module was enabled resulting in database columns not being created and other mess.
This patch removes the stuff that happens on the flush_cache and form alters where it rebuilds the stuff
To make this work properly with this patch (HACKY yes i know!)
you need to enable/disable a module so that your features dependancies are met
then drush fra -y
which will end with the rebuild
gross yes, but it solves the problem for us for the minute until theres a more sane fix, submitting here so that if anyone else is in the same boat it may help them too
Comment #4
pounardUlgy hack, but it makes a lot more sense than rebuilding the features each cron run :)
Comment #5
hefox commented#658772: Provide way to disable rebuild during features_flush_caches()