Last modified: 2014-04-09 19:40:40 UTC
Since the various changes [1] introduced in the Job Queue handling during normal page requests, it caused a lot of problems [2] on installations where the on-request job queue is being used (not on WMF wikis, of course, that's why it went unnoticed until 1.22 was released). The old way of handling the job queue is still present, and will be used if $wgPhpCli is not set to an actual path, or safe mode is on. But still, there's no other way for wikis to revert to the old way unless setting $wgPhpCli to false or an empty string, which may be used for something else and cause other undesired side-effects. We should introduce a configuration setting (for example, $wgUseOldOnRequestJobQueueHandling = true) to revert the job queue handling without interfering with $wgPhpCli, which should default to the old job queue handling, until those issues are fixed, while letting developers and experienced sysadmins enable this *experimental* (at best) feature. ---- [1] https://www.mediawiki.org/wiki/Manual:Job_queue#Changes_introduced_in_MediaWiki_1.22 [2] https://www.mediawiki.org/wiki/Thread:Project:Support_desk/Mediawiki_1.22%2B_Causes_two_of_my_servers_to_hang_indefinitely.
What is the difference towards fixing bug 46934?
(In reply to Andre Klapper from comment #1) > What is the difference towards fixing bug 46934? bug 46934 may or may not describe one of the problems already identified in [1]. This bug is to introduce a $wg variable to provide a way to revert to the old way of running jobs from the queue on page requests, and not having to set $wgPhpCli to false, pontentially breaking something else. Note that the problems with the new job queue handling were introduced in 1.22 (that's why Priority was set to High), while bug 46934 is marked as affecting 1.21, so it may have nothing to do with this one. ---- [1] https://www.mediawiki.org/wiki/Manual:Job_queue#Changes_introduced_in_MediaWiki_1.22
This was all redone a second time in https://gerrit.wikimedia.org/r/#/c/113038/ with one more follow up in https://gerrit.wikimedia.org/r/#/c/116058/ to shore up some edge cases. Ideally MW just falls back if it can't do it in the background rather than needed a config var.
This feature should be called "experimental", or "beta", and be able to fall back to the old one easily, for at least one major version, until we're sure it doesn't break havoc as the 1.22 does. This feature isn't extensively tested until it's released on a major version, because WMF wikis don't use it, and we probably want to support those third party users out there rather than offering them a broken product.
(In reply to Aaron Schulz from comment #3) > This was all redone a second time in > https://gerrit.wikimedia.org/r/#/c/113038/ with one more follow up in > https://gerrit.wikimedia.org/r/#/c/116058/ to shore up some edge cases. > > Ideally MW just falls back if it can't do it in the background rather than > needed a config var. ...which makes this request a low priority, I guess.
Sorry to disagree with you about the priority, but those new changes introduce new problems and now it's even difficult to revert to the old queue. For 1.22 one could set $wgPhpCli to false (while potentially breaking other things, although on 1.22 there seems to be no other functionality using that variable). But for 1.23 there's no way to disable this behavior Also, this is easy, since it only needs wrap the code inside if ($wgNewVariable) { ... } and add a "else" with the old code.
Change 124470 had a related patch set uploaded by Martineznovo: Added $wgRunJobsAsync to allow running jobs the old way https://gerrit.wikimedia.org/r/124470
It's critical to have this in 1.23 release
Change 124470 merged by jenkins-bot: Added $wgRunJobsAsync to allow running jobs the old way https://gerrit.wikimedia.org/r/124470
