Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#001 - Logic to handle child processes (workers) being killed by the OS (for example, due to Out Of Memory (OOM)) #1

Closed
artpdr opened this issue Jan 18, 2019 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@artpdr
Copy link
Collaborator

artpdr commented Jan 18, 2019

I'm creating an issue for this change in condu because it might change a vast proportion of code.
The problem is:

  • When a worker process (child process that polls tasks from conductor server) is killed by the OS, for example due to OOM, there is no way to update the task being treated by the process that is gone as "FAILED".
  • The process that is killed is set as a Zombie process and the task type that was being handled by this process is never polled again from this worker.

The solution that I will provide is:

  • When child processes are triggered, they will be triggered from different threads that maintain a pipe open to the process that is triggered.
  • Whenever the process receives a task from Conductor server it communicates this task with the thread that triggered the process.
  • If the child process is killed, for example due to OOM, the thread that created the process can observe this and can update the task as FAILED and create a new process to replace the one killed before.

For any doubts or suggestions, comment please.

@artpdr artpdr added the enhancement New feature or request label Jan 18, 2019
@artpdr artpdr self-assigned this Jan 18, 2019
@TheBrunoLopes
Copy link
Owner

TheBrunoLopes commented Jan 18, 2019

This seems like a viable approach.
There are a few caveats to should be taken into consideration. It's preferable to use new processes instead of new threads because of the GIL. This builtin library should be able to handle the tasks you propose.

@artpdr
Copy link
Collaborator Author

artpdr commented Jan 18, 2019

Hi @bioslikk long time no see :p.
As the threads will only be used to have a Pipe for the process they create, I think there is no big overhead in context switching between threads.
PS: I'm aware of GIL.
Cheers.

@artpdr
Copy link
Collaborator Author

artpdr commented Jan 18, 2019

It seems that I will need to trigger new processes instead of new threads as launching processes from multi-thread processes seems problematic

@TheBrunoLopes
Copy link
Owner

Yup, that's what I meant to say. Multiprocessing lib is awesome to tackle that problem.

artpdr added a commit that referenced this issue Jan 19, 2019
…w able to reboot processes when they are killed by external sources (e.g., OS).
@artpdr
Copy link
Collaborator Author

artpdr commented Jan 19, 2019

Finished this using just processes. There is no multi-threading....
This will be released in Pypi with version 2.0.0b05

@artpdr artpdr closed this as completed Jan 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants