Worker refactor #933
Labels
Issue appropriate for: People up for a challenge 🤨
This issue probably will be challenging to tackle
Issue contains: Exploration & Design decisions 🤯
We don't know how this will be implemented yet
Issue contains: Some Python 🐍
This issue involves writing some Python code
Issue type: Refactor 🔄
Issues involves rewriting some code in a better way
Current sitation
When the procrastinate worker starts, it will launch n+2 coroutines, n being the concurrency setting.
asyncio.Event
to communicate that new tasks are available.Issues with the current situation
Each subworker requests new tasks from the DB. That's far too many SQL queries. Also, utils.run_tasks is a bit disgusting.
Possible solutions
Instead of having n looping subworkers, we should have a single job spawner that figures out when a new job is available and then launches job coroutines withing asyncio tasks.
We should still respect concurrency, probably using
asyncio.Semaphore
.At this point I'm not 100% sure yet how graceful and especially ungraceful shutdown should look like. I guess the standard "shutdown signal" for a coroutine is
task.cancel()
, so the first request to shutdown that triggers a graceful shutdown should use this. Note that it's already howApp.run_worker_async()
is implemented, but maybe this should be a part of the worker. Then, I guess a second.cancel()
should shut down everything, but still ensure that cancelled job have a special state. I think "failed" is the existing corresponding state, waiting for a proper handling of withdrawn & interrupted tasks (in another ticket)For now this all is up do design discussions.
The text was updated successfully, but these errors were encountered: