Last modified: 2011-12-06 06:50:54 UTC
Steps to reproduce 1) set $wgMainCacheType = CACHE_APC; 2) from commandline (without apc enabled), run dumpBackup.php CACHE_ACCEL requested but no suitable object cache is present. You may want to install APC. Backtrace: #0 [internal function]: ObjectCache::newAccelerator(Array) #1 mediawiki/includes/objectcache/ObjectCache.php(62): call_user_func('ObjectCache::ne...', Array) #2 mediawiki/includes/objectcache/ObjectCache.php(50): ObjectCache::newFromParams(Array) #3 mediawiki/includes/objectcache/ObjectCache.php(23): ObjectCache::newFromId(3) #4 mediawiki/includes/GlobalFunctions.php(3600): ObjectCache::getInstance(3) #5 mediawiki/includes/Setup.php(402): wfGetMainCache() #6 mediawiki/maintenance/doMaintenance.php(98): require_once('...') #7 mediawiki/maintenance/commandLine.inc(64): require('...') #8 mediawiki/maintenance/dumpBackup.php(32): require_once('...') #9 {main} (note some paths have been stripped for security) This worked on 1.17. It is quite common to want APC enabled for www, but not have it running for commandline php.
Correction: I have cache set to $wgMainCacheType = CACHE_ACCEL;
This sort of caching is known to cause problems when mixed with command line utilities or multiple servers. As a workaround, disable the CACHE_ACCEL in your LocalSettings.php with a condition like this: if (php_sapi_name != "cli") { ... } dumpBackup.php should be safe to run in that config, I think, as it won't be making writes and thus needs no cache clears.
Will do. Is this still considered a bug though - I mean if there is no cache available, shouldn't the mediawiki code just not use any cache functions instead of throwing an exception ?
It's a faulty configuration. Some scripts rely on being able to clear the cache (like the password reset script) and having them silently not work is not nice.
am i missing something. If there is no cache in use, then they should work anyway surely. This all worked in 1.17 - and I saw no information relating to needing this logic wrapped around the configuration setting. The sensible thing would be if there is no apc cache as in this case, to fall back on not using a cache. Not failing (which is a change from behaviour from 1.17)
That script would work, but bad data could be left in the caches for your web scripts. Ultimately it's our fault for having this config option available at all when we constantly recommend against it. :P
Jools, Niklas is saying that some cli scripts also do work that involves clearing the web side's cache. ie: There's something cached for the web version, a script from the cli is run, modifies the backing information, and wants to clear that information. If there's a cache on the web but not cache in the cli then that means that falling back to no-cache and purging that means inadvertently the script has thought it cleared the cache when in reality the cache is still there on the web, and the web side of the wiki is still serving outdated information to users.
Thanks for the clarification and help everyone. appreciated.
