If the root job timestamp keys are lost or otherwise unknown, they
will now be deductively recached with the best known values as jobs
are popped and executed. This means the running any of many child
jobs of a root job can restore the root timestamp if it was lost.
This does not need to use the main stash given this fact.
Bug: T227376
Change-Id: Iae0f3af15803af048ff49f3bf281b2bde18c87f2
JobQueueGroup is giving RunnableJob on pop(), so it should take the same
type for ack() and deduplicateRootJob()
JobQueue::ack alsready accept the interface
Also change to RunnableJob in JobRunner to work with the type from the
job queue
Change-Id: I7b09586cff8affabe807ee16e80d04f5137dce45
Simplify the code of jobs that do not care about titles and removes
the direct Title dependency from JobQueue. Remove getTitle() from
IJobSpecification itself. Move all the Job::factory calls into a
single JobQueue::factoryJob() method.
Depends-on: Iee78f4baeca0c0b4d6db073f2fbcc56855114ab0
Change-Id: I9c9d0726d4066bb0aa937665847ad6042ade13ec
Also moved some WikiMap/$wgJobClasses checks to JobQueueGroup::pop
which is the method callers are supposed to use.
Change-Id: I2ab82d8adc4ae1f54697d2935afa2053539cf2db
This was originally a global search and replace. I manually checked all
replacements and reverted them if (due to the lack of type hints) either
null (that would be 0 when counted) or a Countable object can end in the
variable or property in question.
Now this patch only touches places where I'm sure nothing can break.
For the sanity of the honorable reviewers this patch is exclusively touching
negated counts. You should not find a single `!== []` in this patch, that
would be a mistake.
Change-Id: I5eafd4d8fccdb53a668be8e6f25a566f9c3a0a95
Using domains means thats JobQueueDB has the right value to use for calls
like LoadBalancer::getConnection(). The full domain includes the schema in
the case of Postgres. This makes calls to getConnection() less awkward by
not relying on the fallback logic in reallyOpenConnection() for null schemas.
Make getWikiIdFromDomain/isCurrentWikiDomain account for the schema if it
is both defined and is not simply the generic "mediawiki" schema MediaWiki
uses by default. If all wikis use the default schema, the wiki IDs can get
by with DB/prefix alone, which various config and methods may be built around.
Otherwise, the config callbacks must account for schema and the config must
include it in various wiki domain ID lists to properly disambiguate wikis.
Also, clean up SiteConfiguration::siteFromDB() since it is not meant
to handle schemas unless the callback method was taylored to do so.
Finally, add more comments to DefaultSettings.php about already existing
limitations of wiki domain IDs and their components.
Change-Id: I8d94a650e5c99a19ee50551c5be9544318eb05b1
Use these in place of various wfWikiID() calls.
Also cleanup UserRightsProxy wiki ID variable names and removed unused
and poorly named getDBname() method.
Change-Id: Ib28889663989382d845511f8d34712b08317f60e
This assures that MergeableUpdate tasks that lazy push job will actually
have those jobs run instead of being added after the lone callback update
to call JobQueueGroup::pushLazyJobs() already ran.
This also makes it more obvious that push will happen, since a mergeable
update is added each time lazyPush() is called and a job is buffered,
rather than rely on some magic callback enqueued into DeferredUpdates at
just the right point in multiple entry points.
Bug: T207809
Change-Id: I13382ef4a17a9ba0fd3f9964b8c62f564e47e42d
We use $wgReadOnly for various reasons, one of which is to disallow
writes in the currently-non-active DC. However, we should allow the
readOnlyReason configuration variable to be available per JobQueue type
and have it the code respect that.
In our current set-up, we use JobQueueEventBus which ever only uses the
enqueue execution path and does not depend upon which DC it is executed
in, so this will allow us to enqueue jobs in both DCs.
Note that this is an alternative approach to the one outlined in
Ibbad6063b6b154d7f7d172c79f7be324bf80eb7e
Bug: T199594
Change-Id: I8f1a57a81ea11c1c587c0057fa8bb3454b0e0b56
This could possibly use LoggerFactory & friends to use them as
parameters, but either way let's sort the entries so they're
at least remotely capable of self-grouping.
Change-Id: Iaf435093d70add02e2f82e3037c64fec11870979
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
Although issuing PHP notices in unit tests is only a nice-to-have, the cause
is PHPDBG has no special treatment in JobQueueGroup at the contrary of the
PHP SAPI 'cli', and it may be desirable both 'command line SAPIs' have the
same behaviour.
This is the most apparent difference between cli and phpdbg but there could
be a dozen of other occurrences (see bug), potentially creating differences
in unit tests depending on the SAPI.
Bug: T162591
Change-Id: Idf9c14db72f1f768c5a17b49ed689a05922c57d3
This happens post-send anyway, so throwing errors is not
very useful and the other post-send updates are independent.
Change-Id: Ife8f9825da9592be1a38cf4c757550213838463b
Also consistently use self:: instead of BagOStuff:: for constants
referenced within the BagOStuff class.
Change-Id: I20fde9fa5cddcc9e92fa6a02b05dc7effa846742
I am seeing a constant stream of
Notice: JobQueueGroup::__destruct: 1 buffered job(s) never inserted. in
/srv/mediawiki/php-1.26wmf6/includes/jobqueue/JobQueueGroup.php on line 419
In the production logfiles. Log what type of jobs these are so we can figure out
how to fix them.
Change-Id: I7beca910d8c4b20aa20bdec4883e399fd94fbcfd
* This avoids __destruct() warnings
* Also remove push() code in __destruct() that just made
more warnings since it's too late
Change-Id: I32a3cfabc94e36b9d2808b45d55209f3df46e47d
* Made use of this in triggerOpportunisticLinksUpdate()
* This will defer and better batch job insertion
* Lazy job insertion and other deferred updates
make use of register_postsend_function if present
* Also cleaned up some return types and exceptions
in JobQueueGroup
Bug: T99302
Change-Id: I3a3968d75cb37563f970be08e63f31a090e0e037
* Moved all these hacks to JobQueueDB, which is the only queue that
should need this (for stock installs). Newer queues should always
have the queue store manage stuff like this, not MediaWiki.
* This also avoids expensive object construction that does nothing
when non-DB queues are used.
Change-Id: Id718cda25750be73044a049b39958cca55aa3172
Xhprof generates this data now. Custom profiling of various
sub-function units are kept.
Calls to profiler represented about 3% of page execution
time on Special:BlankPage (1.5% in/out); after this change
it's down to about 0.98% of page execution time.
Change-Id: Id9a1dc9d8f80bbd52e42226b724a1e1213d07af7
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: Ifbb1da2a6278b0bde2a6f6ce2e7bd383ee3fb28a
