https://github.com/mfurquimdev/trying-celery
Learning Celery
https://github.com/mfurquimdev/trying-celery
Last synced: about 2 months ago
JSON representation
Learning Celery
- Host: GitHub
- URL: https://github.com/mfurquimdev/trying-celery
- Owner: mfurquimdev
- Created: 2021-02-01T00:50:04.000Z (over 5 years ago)
- Default Branch: master
- Last Pushed: 2023-09-17T01:59:56.000Z (almost 3 years ago)
- Last Synced: 2025-01-13T11:51:18.650Z (over 1 year ago)
- Language: Python
- Size: 9.77 KB
- Stars: 1
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# trying-celery
Execute the following to spawn a worker
```bash
$ celery -A tasks worker --loglevel=INFO
```
Execute the following to submit a task
```bash
$ python request.py
```
The following settings have been tested using celery version 4.3.0 and rabbitmq version 3.8.11.
When executing a celery worker with `task_acks_late = False`, an ack is sent immediately after the woker has taken a message on the queue.
When the worker is unexpectedly terminated (e.g. SIGKILL) before publishing the result, the message will not go back to the queue
On the other hand, when executing a celery worker with `task_acks_late = True`, an ack is sent only after the woker has processed the message.
When the worker is unexpectedly terminated (e.g. SIGKILL) before publishing the result, the message will not have been acked.
Thus, the message will return to the queue.
On both cases, when a SIGTERM is sent, the worker finishes the task and publishes the result.
Neither `task_acks_on_failure_or_timeout` nor `task_reject_on_worker_lost` seem to have any effect on the status of the queue when killing the worker.