Some entry points stream output and flush their own headers.
This avoids "headers already send" warnings in some cases.
Change-Id: Ifb232d4575486749bbbccba88f3f688972fe9c20
Remove the exit(1), which does not seem to be needed by any callers.
Doing so means that post-send updates can still happen, such as the
pushing of lazy jobs.
Better avoid showing exceptions in doPostOutputShutdown(), given
that an error may have already been shown. By the post-send part,
it's to late to show errors anyway.
Bug: T100085
Change-Id: Ib1c75323f222a0e02603d6415626a4b233e8e1c7
Previously, tryOpportunisticExecute() tried to nest transaction rounds,
which would fail. Added LBFactory::hasTransactionRound() as needed.
Also cleaned up some unqualified class names in callbacks and set the
PRESEND flag for the JobQueueDB AutoCommitUpdate callback. Use the
proper getMasterDB() method while at it. These follow up 24842cfac.
Bug: T154425
Change-Id: Ib1d38f68bd217903d1a7d46fb15b7d7d9620daa6
This is needed for deferred updates LinksDeletionUpdate and LinksUpdate, else
callbacks registered with onTransactionIdle prevent other transactions from
being executed, at least in this case.
Bug: T154425
Bug: T154438
Bug: T157679
Change-Id: Iecd396d584a62ac936cd963915339159467b44cd
In the postprocessing, some jobs can be executed but given the deferred
updates were already "closed", any new DeferredUpdate were directly called
(as explained by Krinkle on T165714), and the transactions opened by
classical jobs are badly mixed with transactions (directly) executed by
DeferredUpdates jobs, issuing a DBError, avoiding the job, which stays
in a 'claimed' status even if failed.
Quite similarly, some DeferredUpdates callables use JobQueueGroup::lazyPush
so it is needed to really push the generated jobs.
This change removes the run-immediately-deferred-updates behaviour even
in the post-connection shutdown, and given there is a call to
DeferredUpdates::doUpdates in JobRunner::execute it is not necessary to
add another one and hence execution of Web jobs is more similar to execution
of CLI jobs. In the same spirit to reconcile Web jobs and CLI jobs, the
call to JobQueueGroup::pushLazyJobs is done in JobRunner::execute.
Bug: T165714
Bug: T100085
Change-Id: I721e7167eca5b0b6227234fe516005243ab22388
This catches things like "DB is read-only" when doing pop()/ack() from the
job table with sqlite.
Also spun off some code to new trigger*Jobs() methods for readability.
Bug: T88312
Change-Id: I2a09248e40867684d48e6739da5e4a90581fa6ce
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
It's only called once, and that call is static. It also doesn't use $this.
[error] /w/index.php?title=New_new_page&action=purge
ErrorException from line 610 of /vagrant/mediawiki/includes/MediaWiki.php: PHP Strict Standards: Non-static method MediaWiki::getUrlDomainDistance() should not be called statically
Change-Id: Ice66937a32193720c52df39bcea90659a8d9f653
This is useful if the ChronologyProtector store cannot sync
among datacenters and waitForReplication() is DC-local.
It only applies if the user stays on the domain, however.
Change-Id: I800cade7b87a0f02d6a429e70924c54189a4a7af
* Use OutputPage::output() as the method to mask latency, since it
takes a good while to run. By the time it runs, cache replication
should have caught up, so the reap call will likely not block.
* For redirects emitted after changes in POST, instead of masking
with OutputPage, add a parameter to the redirect and block on
the positions appearing. This uses the redirection RTT to mask
the replication latency.
Change-Id: Ib23690c302e8033610fef9a0ef451dafe8a5803e
* Avoid deprecated method use in MediaWiki.php.
* Move LBFactory::beginMasterChanges down a bit, next
to LBFactory::commitMasterChanges.
* Rename $factory => $lbFactory.
* Remove redundant $conn->trxLevel() check.
Change-Id: I309ff3b8e3f586f0ac40b2f3be26b161993b58d2
This makes sure that jobs run one way or another.
Also made a few cleanups and improved the logging.
Change-Id: Ic2916099181ebeb5ae5143d444515db9ed13cee9
* Follow-up to 8b141886ed
* The method is now called after the setCdnMaxage() call
in performAction.
* Allow any CDN urls for the title now, check $wgDebugToolbar,
and allows caching redirects. The multi-step redirect case does
not cache however, for simplicity.
* Removed now-unused code in Article that calculated $timestamp.
Change-Id: Ic4f4e3a79d7d386c2f15ca5b11dddf5c57ff9e9f
This updates are PRESEND for reason, so users should see them
on the next page view. Otherwise, they would be POSTSEND.
Change-Id: I533de550f6dd3e4b75507c2d25b1a05f7ac1301d
* Use getCanonicalURL() to avoid links with the wrong host (e.g.
when it is virtual) and to avoid getting redirects.
* Also disable this setting when post-send execution is already
available, by default.
* Bump the socket timeout slightly.
Bug: T107290
Bug: T68485
Change-Id: I56c43193fa6583cc0c8209ff59cf20c986a799a3
This makes post-send updates subject to logging, like other
updates in POST requests. Previously, slow queries were ignored.
Bug: T137326
Change-Id: Ia08f51a10b7b1fae3350f5c5215fab234edefada
Most URL generation happens via wfExpandUrl, which honors $wgServer
(or whatever setting it is told to use): if it has an explicit
protcol, that is always used; if it is a protocol-relative URL,
the protocol is selected based on the parameters given to wfExpandUrl.
One exception is MediaWiki::main() which always uses HTTPS if the
relevant cookie or user option is set, even if the wiki does not
support it. That can lead to annoying problems on Vagrant where it
is not unusual to turn HTTPS support on and off: when that happens,
the user can get locked out of the account.
Change-Id: I06982a26cd808f2aaa26753cd3353ed82473d9e0
The former sometimes show up in the logs as they were causing
CentralAuth to use the master but the expectations treated
the request as a GET request. This makes things more
consistent.
Bug: T92357
Change-Id: I55bf3139c68f5926fe67a51cf0eb1b2ffe55d17b
* This is useful for logic that decides what DB (master/slave) to use
based on the nature of the web request. It could also be used to
enforce clear read/write distinctions via exceptions if DB_MASTER
is misused.
* Also fixed two IDEA errors while editing this class.
Bug: T134608
Change-Id: I43f4bc06c19d823d7d1ffd9cee8bbe60563c7f82
* Timeouts happen when memcached is cleared or on DC-switchover likewise
* Disable the sidebar cache when the MessageCache is disabled
* Also lower any output expiry for CDN and set a custom header
when the MessageCache is disabled
* Log when this happens to a dedicated "MessageCacheError" channel
Bug: T133069
Bug: T7092
Change-Id: I1b80e250532033c52680246279e1e8f56350ae83
Special page instance from SpecialPageFactory::getPage needs a context
set, to avoid using RequestContext::getMain in SpecialPage::getContext
Change-Id: I6e0828c6c9668c4ef10a729533190a5225b8782f
