I have implemented this into beanstalkd but I think it should also be implemented here in the drupal_queue_cron_run().
This is what I did in beanstalkd and I am wondering this should also be done in drupal queue.
try {
beanstalkd_log(t("Processing job @id for queue @name", array('@id' => $item->id, '@name' => $item->name)));
ini_set('display_errors', 0);
$function($item->data);
ini_set('display_errors', 1);
return TRUE;
}
catch (Exception $e) {
beanstalkd_log(t('Exception caught: @message', array('@message' => $e->getMessage())));
$queue->releaseItem($item);
return FALSE;
}
Basically if a job crashes it will release the item so that it can be processed again, which could or could not crash again depending on the error. Most of the time I get out of memory errors so releasing the job to be reprocessed is a good thing.
Gordon
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 1020954-8-cron_run_release.patch | 605 bytes | Grayside |
| #6 | 1020954-5-cron_run_release.patch | 606 bytes | Grayside |
| #4 | 1020954-4-cron_run_release.patch | 606 bytes | Grayside |
| #2 | 1020954-cron_run_release.patch | 605 bytes | Grayside |
| #2 | d6_backport-1020954-release_on_cron.patch.txt | 586 bytes | Grayside |
Comments
Comment #1
dave reidAny features need to come directly from Drupal 7 core's queue API. Feel free to re-open and transfer this issue to the core queue for consideration.
Comment #2
Grayside commentedIf the item processing callback function returns TRUE, delete the item out of the queue. Otherwise release back to the queue.
Comment #4
Grayside commentedFailed to account for backwards compatibility. Now the return value concept is "TRUE" for the non-standard behavior of leaving the item on the queue for another worker, and no effort needed to delete the item from the queue.
Comment #6
Grayside commentedWrong patch.
Also, leaving additional backport rerolls until this gets farther along.
Comment #8
Grayside commented>.>
Comment #9
gordon commentedThis will not work, since the function doesn't return anything to say that it has been successful or not.
How I did it in beanstalk is to have it catch any errors and then release it when an error occurred.
Powered by Dreditor.
Comment #10
gordon commentedComment #11
Grayside commentedWhy can't the function return something optionally in order to trigger release behavior? Error catching as a logical flow trigger does not seem a common pattern in Drupal.
Comment #15
jhedstromUsing a try/catch pattern, as outlined in the issue summary, in Drupal 8 would be preferable.
Comment #28
smustgrave commentedThank you for sharing your idea for improving Drupal.
We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #30
smustgrave commentedSince this was a feature request and there's been no follow up going to close out. Assigning credit for the early patches. This can always be re-opened if so lets get a summary update as well please.
Thanks all.