OOM errors leave queuedjobs unrecoverable about silverstripe-queuedjobs HOT 6 CLOSED

Ok, it looks like in our case QueuedJobsService::$memory_limit was EXACTLY set to the server limit, so there was no chance for the queue to safely escape.

from silverstripe-queuedjobs.

I've come up with a fix; Hope it meets the expected high quality of contribution. ;D

from silverstripe-queuedjobs.

It's a problem with any fatal error, in that the job is left "Running". There's some logic in checkJobHealth that will actually see whether a descriptor has incremented its "steps processed" field (ie currentStep from within the job), but that only kicks in if StepsProcessed is greater than 0. One way to work around things is to set currentStep in the constructor when first creating the job...

from silverstripe-queuedjobs.

Ok thanks @nyeholt :D

I wonder if we could improve the check to work even if StepsProcessed is 0; I've raised an internal ticket pointing at this open source issue and will try to schedule some time to properly resolve this.

from silverstripe-queuedjobs.

Yet another potential improvement at #43

It doesn't stop the module from crashing, but ensures that jobs are recoverable.

from silverstripe-queuedjobs.

I think this is issue obsolete with the new doorman backend. :)

from silverstripe-queuedjobs.