In my opinion, the existing Job Queue is awfully close to being suitable for my media
recoding needs. Rather than recreating a very similar mechanism just for queueing media
recoding jobs, I wonder if it would be okay for me to make a few changes that would make
it a little more robust and suitable to my needs.
Currently, JobQueue::pop_type() just gives up on finding a job to do if it finds that the
first one it has selected already got taken by a concurrent process. I believe this could
be improved easily by just returning a recursive call:
if ($affected == 0) {
wfProfileOut( __METHOD__ );
//used to be: return false;
//but there may still be other jobs of $type we can claim...
return self::pop_type($type);
}
...but since this hasn't been done already, I'm afraid there's some reason for
it to be as it is. This is safe and behaves as expected when no more jobs of $type exist.
There's no way this could break any client code, since it has no idea whether this
condition will occur when it calls pop_type. Any other reasons not to do this?
Also, I want to populate the job queue with things that cannot be run on just any machine,
probably including those that currently pop() from the job queue. To prevent this from
happening, I could:
-make a new table structurally identical to job, and make a child class of JobQueue that
just redefines a class constant containing the table name.
-add a flagging column to the current job table that JobQueue::pop() checks for and skips
over if the flag is on
-just hardcode job types that shouldn't be claimed into pop() so they will only be
taken on pop_type() calls.
I don't know how much changing database structure makes people's lives difficult
at upgrade time, so I'm not sure which of these would be best in the event that my
work eventually proves itself worthy of inclusion in mainline MediaWiki.
Mike
Show replies by date