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

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T19622, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 17622 - CentralNotice is broken
CentralNotice is broken
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
CentralNotice (Other open bugs)
unspecified
All All
: Normal enhancement with 1 vote (vote)
: ---
Assigned To: Tomasz Finc
http://test.wikipedia.org/w/index.php...
:
Depends on:
Blocks:
  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: ---


Attachments

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, 

test/aa
test/ab
test/ace
test/af
test/ak
test/aln
test/als
test/am
test/an
test/ang

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.


Navigation
Links