Page MenuHomePhabricator

DBA caching backend is broken in MW 1.18 ($dir is an array)
Closed, ResolvedPublic

Description

In MediaWiki 1.18, when you set DBA as the main caching mechanism ($wgMainCacheType = CACHE_DB) you'll run into an error.

In includes/objectcache/DBABagOStuff.php on line 17 you check if $dir === false or not. In my case it isn't, so you assign its value to $this->mFile = "$dir/mw-cache-" . wfWikiID();.

The problem is that from v1.18 on the $dir is an array.

I got the following when I print_r'd the $dir variable in the first line of the __construct function: Array ( [class] => DBABagOStuff ).

Of course in this case the $this->mFile = "$dir/mw-cache-" . wfWikiID(); line will be broken also and that's why later MW cannot open the DBA cache.

For an ugly workaround I forced the $wgTempDirectory to be assigned to the $dir variable:

if ( $dir === false || is_array($dir) ) {
global $wgTmpDirectory;
$dir = $wgTmpDirectory;
}


Version: 1.18.x
Severity: major

Details

Reference
bz32853
ReferenceSource BranchDest BranchAuthorTitle
repos/cloud/toolforge/maintain-harbor!21delete_stale_artifactsmainraymond-ndibe[maintain-harbor]: cleanup old production images
repos/cloud/toolforge/maintain-harbor!20delete_stale_artifactsmainraymond-ndibe[maintain-harbor]: cleanup old production images
repos/cloud/toolforge/maintain-harbor!18delete_stale_artifactsmainraymond-ndibe[maintain-harbor]: cleanup old production images
repos/mediawiki/services/ipoid!123fix-delete-querymaintchandersRemove unnecessary subquery from DELETE statements
Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 12:04 AM
bzimport set Reference to bz32853.

We did some refactoring for the object cache refactoring. I did send a patch as r105419 which might apply to 1.18 as is.

Once patch is applied, you will be able to configure the CACHE_DBA backend using:

$wgObjectCaches[CACHE_DBA]['dir'] = '/some/directory/'

Keeping bug open until revision is reviewed in trunk, will then back port it to 1.18 and mark this bug fixed.

backported in REL1_18 with r105706 will be in 1.18.1

Please note another developer advise against the use of CACHE_DBA except for testing :D

Thank you for the quick fix!

On a shared hosting I think this is the "best" solution before CACHE_NONE, so I'm forced to use this.

Fortunately, if everything goes well we'll move to an other server where APC will be turned on, so we can forget the DBA caching.