A solution/workaround for the caching problem that I asked about as quoted below.
It only seems to occur only after restoring a backed-up MediaWiki 1.5.8 database and then running maintenance/update.php from the 1.6.5 instance's directory so that the later versions can also access this database.
The problem can be resolved when it occurs by running "php rebuildMessages.php --rebuild" in the same maintenance directory. There doesn't seem to be a need to restart memcached.
On Wed, 10 May 2006 19:43:43 +1000, Netocrat wrote: [...]
I'm encountering some MW + memcached problems on my development machine and before looking more closely wanted to run them by the list in case there's a quick answer like "that problem's expected with your set-up - do it differently".
I first noticed that intermittently the treeview's caching is failing - that the call to save its data structure to cache completes but on the next request the treeview is rebuilt again - a time-consuming operation
- because the attempt to load it from cache comes up empty. The problem
seems to be related to a message that has recently started showing up in the debug log (many times per request when it appears, but sometimes not at all) as: memcached: Error parsing memcached response I later enabled memcached logging by setting $wgMemc->_debug true but a cursory look at the new output didn't give me any more insight.
Some information that might be relevant:
- I run several versions of MediaWiki on the one machine sharing a
database (including table prefix) and memcached server. No version in use is earlier than 1.5.8; the latest is a fairly up-to-date svn checkout. I haven't researched whether such a setup "should" work. I have noticed (tangentially related) that some cache keys don't seem to include $wgDBprefix as a component.
- The problem persists after restarting memcached and limiting browsing
to one of the MediaWiki instances.
- I encounter (and have been encountering for a long time prior to this
problem) other occasional problems with messages showing up in html output as ###NONEXISTENT### that it's not simple to remedy - the interactions between messages in language files, in the database and in the message cache is something I've not yet looked closely at, and it's complicated by my addition and modification of messages in(to) php files whilst developing. I'll have a closer look if there's no simple or quick explanation.
- I recently installed eAccelerator on my development machine. Prior to
its installation I hadn't noticed this problem. * Cache settings in LocalSettings.php for each instance are: $wgUseMemCached = true; $wgMainCacheType = CACHE_MEMCACHED; $wgMemCachedServers = array ( [identical server for each] ); $wgEnableParserCache = true;
[...]