Last modified: 2009-03-11 17:56:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 17622 - CentralNotice is broken
CentralNotice is broken
Product: MediaWiki extensions
Classification: Unclassified
CentralNotice (Other open bugs)
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Tomasz Finc
Depends on:
  Show dependency treegraph
Reported: 2009-02-22 23:55 UTC by Casey Brown
Modified: 2009-03-11 17:56 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Casey Brown 2009-02-22 23:55:41 UTC
CentralNotice is no longer working (displays "<centralnotice-template-test_notice>" instead of the notice).  It would be helpful if this could be fixed as soon as possible (we need it for Wikimania).  Adding a bug here to document the issue and then hopefully we can have the solution listed here when the issue comes up again.
Comment 1 Tomasz Finc 2009-02-25 02:06:21 UTC
Fixed the initial problem of the cron not running due to permission issues. The secondary issue is why the cron retrieves a failed message from the mediawiki store, while running the script by hand produces the correct output.
Comment 2 Tomasz Finc 2009-02-25 03:22:31 UTC
Interestingly enough this bug is only triggered when a large amount of messages (10+) are being retrieved for a template. 

For instance, 


all generate correctly while anything after will fail. But run those templates that fail by hand one by one and everything works out just fine.

Have we imposed any new restrictions on the throughput of message pulls? Time for me to find out.
Comment 3 Tim Starling 2009-02-25 03:57:12 UTC
Out of memory?
Comment 4 Tomasz Finc 2009-02-25 23:53:20 UTC
Quite possibly. 

I'm also seeing this bug in the all language view for Special:CentralNotice making me suspect less that the rebuild is at fault and that something internal could be malfunctioning or being used improperly.

Brion suggests looking at MessageCaching.php or Language.php to further diag.
Comment 5 Brion Vibber 2009-02-28 02:22:29 UTC
"Out of memory" as such should just cause a failure; but I do recall seeing some weird stuff before with cached language objects getting corrupted (in that case when having the destructor run during parser test runs, but the emptied-out object retained in a cache array and returned by a later fetch). Could be something similar.
Comment 6 Tomasz Finc 2009-03-10 10:09:13 UTC
There is defiantly something funny going on at the caching layer.  $this->mMemc->add() within MessageCache is failing when it pulls any message past test/ang. This failure causes mDisable to be set and each subsequent call for messages will fail outright.

The memcache add is currently failing with "SERVER_ERROR out of memory" errors" . 
Comment 7 Tim Starling 2009-03-10 13:48:31 UTC
Sounds like it's trying to set a value that is larger than memcache's compiled maximum, which is most likely 1MB after gzip compression.
Comment 8 Tim Starling 2009-03-10 22:32:10 UTC
Actually it seems to have been a problem with the memcached instance in question, on srv63. I restarted it.
Comment 9 Tomasz Finc 2009-03-11 17:56:56 UTC
Cached message are now getting properly set. I've re-enabled the cron for all messages and have it set to generated at 30min intervals. I'll be keeping an eye out on the memcached node in question.

Note You need to log in before you can comment on or make changes to this bug.