Last modified: 2014-02-11 20:12:51 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 T62217, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 60217 - Support one-time job scheduling
Support one-time job scheduling
Status: NEW
Product: MediaWiki
Classification: Unclassified
JobQueue (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 61148 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-19 00:47 UTC by Adam Wight
Modified: 2014-02-11 20:12 UTC (History)
4 users (show)

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


Attachments

Description Adam Wight 2014-01-19 00:47:26 UTC
I'd like to enqueue a job which will not be run until a specified time in the future.

Currently, my only option seems to be something really evil involving backoffs and a Job::run() method which intentionally fails until the desired time.

Ideally, we could deprecate the mw-runJobs-backoffs.json system in favor of a not_until column in the `job` table.

My use case is almost too hypothetical to mention: a workflow engine which can do things like abandon AfD cases after a set number of days.
Comment 1 Nik Everett 2014-02-10 17:46:39 UTC
*** Bug 61148 has been marked as a duplicate of this bug. ***
Comment 2 Nik Everett 2014-02-10 17:47:10 UTC
It'd be nice to be able to register a job to execute after a certain amount of
time.  My particular use case revolves around Elasticsearch's refresh interval:
once you push something to it you have to wait a second before you can query
that new data.  Since we use Elasticsearch to count links we'd like to be sure
that updates that we just performed have hit the index.
Comment 3 Nik Everett 2014-02-10 17:48:34 UTC
Merging the bug I just filed with this one as they are pretty much the same.  I will, though, bump the priority because my use case is not hypothetical.
Comment 4 Nik Everett 2014-02-11 18:41:19 UTC
Looks like JobQueueRedis supports a "jobReleaseTimestamp" timestamp.  I'll play with it.
Comment 5 Nik Everett 2014-02-11 20:12:51 UTC
OK, so three things:
1.  You have to turn it on even if you are using the redis job queue:
 $wgJobTypeConf['default'] = array(
 	'class' => 'JobQueueRedis',
 	'order' => 'fifo',
 	'redisServer' => 'localhost',
 	'checkDelay' => true,
 	'redisConfig' => array(
 		'password' => $wgRedisPassword,
 	),
 );

2.  If you try to use 'jobReleaseTimestamp' when it isn't on you'll get an error.  So if you want to optionally use it, you need something like this:
	$jobQueueGroup = JobQueueGroup::singleton();
	$jobQueue = $jobQueueGroup->get( 'cirrusSearchLinksUpdateSecondary' );
	if ( $jobQueue->delayedJobsEnabled() ) {
		$params[ 'jobReleaseTimestamp' ] = time() + 60;
	}

3. WMF doesn't have this on right now.  I wonder why.

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


Navigation
Links