Hi again,

I've tried searching, and tried the ajax hotfix here http://drupal.org/node/1839122 in case, but to no avail.

my files: https://gist.github.com/4291539

Since 2.0.3 and now 2.0.4, I have had major problems with redis cache. Most recently, on a fresh site build on a dev. subdomain, I tried changing the theme, and as soon as I view the site anonymously, the theme was still bartik. Nothing I could do would show the theme change except ?noredis=1, and eventually resorting to /cache /NO.txt. Problem solved. This particular site is on a custom platform in /static, however I've tested dev. and non dev D7 sites in the standard octopus installs with the same results.

I have not enabled any performance modules of any kind, just a basic d7 install, and a few modules in sites/all/modules. I don't know if its supposed to exist in the modules list, but I have no redis module displaying there.

Any ideas? Thank you very much :)

Comments

omega8cc’s picture

Component: Code » Miscellaneous

You shouldn't use dev. subdomain for anything other than debugging WSOD or you will have such issues. But if you have issues also with non-dev URLs, it is rather weird, especially if you have applied the hotfix - maybe try it again:

wget -U iCab http://files.aegir.cc/update/global-fix.sh.txt
bash global-fix.sh.txt
rm global-fix.sh.txt

Also, remove and uninstall Purge and Expire modules, then clear all caches and then force Redis restart with:

/etc/init.d/redis-server stop
sleep 1
killall -9 redis-server
rm -f /var/run/redis.pid
rm -f /var/lib/redis/*
sleep 1
/etc/init.d/redis-server start
leevh’s picture

Thank you once again for quick reply!

I have renamed my dev site to d.newsite.com instead of dev.newsite.com, reapplied the hotfix (as root), cleared the caches (I had no cache modules ever enabled on that site) and restarted redis. It works the first time, but not after that. I assume because its cached again. Only /cache /NO.txt makes the proper theme show when selected.

As a test, I installed a fresh drupal7.mysite.com site on Drupal 7.17.1 P.004. I logged in and changed the theme and logged out and found again that it hadn't changed. Clearing cache and checking in another browser, still the theme had not changed for anonymous user. Tried changing the theme multiple times to no avail. It picks up content changes just fine.. Added the /cache /NO.txt again to the Drupal 7.17.1 P.004 and it worked fine.
)
Regarding the use of dev.*, I was under the impression that it was ok to use for theme development, so I didn't have to contantly clear cache and could use firebug. (http://omega8.cc/how-to-disable-all-caching-and-aggregation-115) Did I misunderstand the point?

If there are any other files I can supply, I'd be glad to. Thanks for your time!

omega8cc’s picture

Component: Miscellaneous » Code
Category: support » bug

This is rather weird, but I could reproduce this many times. However, I don't think it is just Redis related, since in my test, even adding ?noredis=1&nocache=1, at least on the homepage, didn't help. I had to run "Flush all caches" task in Aegir to get the theme really changed for anonymous visitors. This definitely needs further debugging.

omega8cc’s picture

Status: Active » Needs work
omega8cc’s picture

OK, found it. We should really remove all those exceptions we have added while debugging many initial issues with Redis - some other related issues:

#1593794: New redis-only caching backend settings cause a few issues
#1536872: Caching issues on D7 platforms with Redis module existing
#1555210: cache_clear_all() does nothing
#1535546: D7 site still shows "site in maintenance mode" after it was put live

There should be only one exception:

$conf['cache_class_cache_form'] = 'DrupalDatabaseCache';

However, it will require some testing, to make sure we didn't introduce regressions.

omega8cc’s picture

Title: Redis issues with d7 » Too many Redis caching exceptions cause serious confusion

Better title.

omega8cc’s picture

Status: Needs work » Fixed

Fix committed: http://drupalcode.org/project/octopus.git/commit/4b41788

I believe this should be our safe default. If any site will need exceptions for some reason, they can be easily added in the site specific local.settings.php file - we have moved examples to the override.global.inc file.

To apply the hot-fix without BOA upgrade, you can run:

wget -U iCab http://files.aegir.cc/update/global-fix.sh.txt
bash global-fix.sh.txt
rm global-fix.sh.txt

Thanks for the helpful report!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.