Skip to content
This repository has been archived by the owner on Jul 3, 2024. It is now read-only.

Handling memory fatal errors #142

Open
mstrychalski opened this issue Jun 28, 2018 · 3 comments
Open

Handling memory fatal errors #142

mstrychalski opened this issue Jun 28, 2018 · 3 comments

Comments

@mstrychalski
Copy link

Sometimes it can happen, that script will allocate too much memory (eg. pdf generation) and then it throws uncatchable fatal error.

SlmQueueDoctrine recovers those jobs and runs it over and over, not firing up any event, and I can't find any way to handle those errors. I can set executionTime for recover, and they will not be recovered, but those jobs are still left unprocessed in database, and they just die silently.

What I need to do, is to not recover jobs, and set some things, eg. using Strategy. When memory is out, I can't do anything besides registering new register_shutdown_function, rising memory limit and do what I want. But this is reduntant, because I am already using Strategies to catch errors, send them to raygun or log them.

In this case nothing seems to work, script is stopped, slmqueue is trying to recover it, and it is stopped again. No event fired.

Is there any way to mark those jobs as finished with error, unrecoverable?

@basz
Copy link
Collaborator

basz commented Jul 1, 2018

SlmQueueDoctrine recovers those jobs and runs it over and over, not firing up any event, and I can't find any way to handle those errors.

I don't think this is correct. When a Job is processed (status goes to 2) and the workers dies for whatever reason the job is left inside the table with status 2 as if it is still running. SlmQueueDoctrine doesn't do anything special unless you explicitly throw a ReleasableException or BuryableException inside your job itself.

If you have thrown a ReleasableException the Job would be marked as pending again. Are you sure you aren't doing this...

@mstrychalski
Copy link
Author

mstrychalski commented Jul 1, 2018

Sorry, I meant --recover feature. There is no problem, that worker is failing, and there is no problem with --recover, that tries to run that job over and over, if status is 2. This is correct. I was talking about a way, to just handle an error, or do anything with a failed job.

When fatal error will happen, worker will be killed, and there is no way to save information about it anywhere. Only thing, that will inform me, that job failed is a client, that will show me a screenshot with his job frezzed at status 2. And the logs, that I usually don't read if I don't have to.

Ideal situation is that, when fatal error will be thrown, then worker will be killed, and after restart, will be trying to do that job again (--recover). If it will fail for nth time, then job will be popped out from a queue, and proper event will be fired, and I can send error to raygun or save in database. For me to know, that something gone wrong.

Other good option is when worker fails, then job is marked as failed or just popped out from queue after restart. Anything, that will be a sign that something goes wrong, and I can check it out by querying database or something.

And that was idea of my question. Is it possible with slmqueuedoctrine? To just handle fatal error? Regular exceptions are handled in proper way, event is fired, and I can do magic. In case of fatal error I just don't know anything about them.

@basz
Copy link
Collaborator

basz commented Jul 1, 2018

No in php it is not possible to recovery from fataal errors. In fact the is a list of Error types you can not recovery from

The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants