- If you don’t wish for the errors to propagate then you can disable that by passing the propagate argument:
- All tasks created using the task() decorator will inherit from the application’s base Task class.
- Note that the worker will acknowledge the message if the child process executing the task is terminated (either by the task calling sys.exit(), or by signal) even when acks_late is enabled. If you really want a task to be redelivered in these scenarios you should consider enabling the
- Time limits are convenient for making sure all tasks return in a timely manner, but a time limit event will actually kill the process by force so only use them to detect cases where you haven’t used manual timeouts yet.
- The default prefork pool scheduler is not friendly to long-running tasks, so if you have tasks that run for minutes/hours make sure you enable the -Ofair command-line argument to the celery worker
- If you’re using RabbitMQ (AMQP) as the broker then you can install the librabbitmq module to use an optimized client written in C:
$ pip install librabbitmq
The ‘amqp’ transport will automatically use the librabbitmq module if it’s installed
- Queues created by Celery are persistent by default. This means that the broker will write messages to disk to ensure that the tasks will be executed even if the broker is restarted.But in some cases it’s fine that the message is lost, so not all tasks require durability. You can create a transient queue for these tasks to improve performance
- For long-running tasks to send task progress you can do something like this
- While countdown is an integer, eta must be a datetime object, specifying an exact date and time (including millisecond precision, and timezone information)
- Celery will automatically retry sending messages in the event of connection failure, and retry behavior can be configured – like how often to retry, or a maximum number of retries – or disabled all together.