| Project: | Job queue |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (works as designed) |
Issue Summary
I use job-queue to queue webservice calls - so a failed ws call is put into the queue and tried again later.
However I ran into a problem with the current job dequeuing code. When a job creates another job, it might be dequeued just after creation - which isn't ideal...
Attached is a patch which simplifies the dequeuing code to use just a single query to get the jobs and so solves this problem. Furthermore the fix has some other improvements.
* The current count query doesn't treat jobs that are set to be not run. So the module tries to dequeue too much jobs - which is in particular problematic when there are newly created jobs like I described. The attached fix has no such counting problems.
* It uses a single query to get the jobs vs. possible 1 + number of jobs queries. So it should be faster.
Attached are patches for 5.x and 6.x.
Off-topic:
I've furthermore built a mechanism to disable my jobs, when my webservice seems to be not available. It might make sense to support something like this by offering suiting API functions. We could improve job_queue a bit to better support this - but that's another topic.
| Attachment | Size |
|---|---|
| job_queue_5.patch | 2.79 KB |
| job_queue_6.patch | 1.95 KB |
Comments
#1
#2
bump
In the meanwhile I had this patch running on a production site - it runs fine.
#3
I'd propose to keep job_queue_dequeue, so I fetched fago's idea for the attached patch.
Notes:
* added a
static $query_resultfor only need to query once*
$requery* added ability to call a job via jobid in
job_queue_execute($job), as$jobcan also be an ID* kept original _cron
#4
fixed patch, tehre was some part of another patch in it
#5
correction due to a wrong variable
$jobres#6
This is already handled in job_queue_cron() by not running more jobs than are in the queue.