-
Notifications
You must be signed in to change notification settings - Fork 19
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
Use a real queue worker #4680
Comments
There are multiple available choices. The most known one is probably Celery and maybe Apache Kafka.
With all things considered, I think going with celery is the best. |
This follows https://docs.celeryq.dev/en/stable/django/first-steps-with-django.html to add celery as a dependency and queue worker. A worker still has to be called in docker-compose and added to kubernetes
[#4680] Start adding celery as a queue worker
[#4680] Start adding celery as a queue worker
The worker should only start once the web service is healthy and has run all migrations [#4680] Start adding celery as a queue worker
celery does require a broker. We aren't doing a lot of things that require many async actions nor do we need a super fast broker. Moving tasks to their own files will be enough to allow an easier migration to celery at some point in the future. [#4680] Use a real queue worker
The command is of course in the container [#4680] Use a real queue worker
It was also necessary to add a healthcheck for the service [#4680] Use a real queue worker
Celery requires rabbitMQ or some other message queue. Seems like an unnecessary hassle for what we want to do (run a few jobs async). It's not like we're some high throughput application. Should we require high performance, multiple workers, and 5 9s for async tasks, we can talk about rabbitmq, kafka, etc. Going with django-q which simply allows using postgres for queuing tasks. |
celery does require a broker. We aren't doing a lot of things that require many async actions nor do we need a super fast broker. Moving tasks to their own files will be enough to allow an easier migration to celery at some point in the future. [#4680] Use a real queue worker
The command is of course in the container [#4680] Use a real queue worker
It was also necessary to add a healthcheck for the service [#4680] Use a real queue worker
It was also necessary to add a healthcheck for the service [#4680] Use a real queue worker
When loading the task dictionary, it looks like the referenced function is also dereferenced into a function object. Co-authored-by: zuhdil <zuhdil@gmail.com>
When loading the task dictionary, it looks like the referenced function is also dereferenced into a function object. Co-authored-by: zuhdil <zuhdil@gmail.com>
There's no need to do other stuff as the backend container should be in charge of that [#4680] Use a real queue worker
It expects a list or args, not a string as it makes arg parsing more difficult [#4680] Use a real queue worker
The probe takes more than 1 second to execute and the default timeout for the execution is 1 second. [#4680] Use a real queue worker
[#4680] fix: timings for worker container readiness and liveliness probe
Currently, RSR uses cronjobs to handle one-time background tasks. Using a proper queue worker opens up the possibility to defer tasks to the queue such as sending email and processing data that was previously done in the request handler.
The text was updated successfully, but these errors were encountered: