This document describes the current stable version of Celery (3.1). For development docs,
- Short for acknowledged.
- Workers acknowledge messages to signify that a message has been
handled. Failing to acknowledge a message
will cause the message to be redelivered. Exactly when a
transaction is considered a failure varies by transport. In AMQP the
transaction fails when the connection/channel is closed (or lost),
but in Redis/SQS the transaction times out after a configurable amount
of time (the visibility_timeout).
- Originally a synonym to call but used to signify
that a function is executed by the current process.
- Fork of the Python multiprocessing library containing improvements
required by Celery.
- Sends a task message so that the task function is
executed by a worker.
- Celery release 3.1 named after song by Autechre
- The context of a task contains information like the id of the task,
it’s arguments and what queue it was delivered to.
It can be accessed as the tasks request attribute.
- Workers execute task requests.
- Idempotence is a mathematical property that describes a function that
can be called multiple times without changing the result.
Practically it means that a function can be repeated many times without
unintented effects, but not necessarily side-effect free in the pure
sense (compare to nullipotent).
- Python messaging library used by Celery to send and receive messages.
- describes a function that will have the same effect, and give the same
result, even if called zero or multiple times (side-effect free).
A stronger version of idempotent.
- prefetch count
- Maximum number of unacknowledged messages a consumer can hold and if
exceeded the transport should not deliver any more messages to that
consumer. See Prefetch Limits.
- prefetch multiplier
- The prefetch count is configured by using the
CELERYD_PREFETCH_MULTIPLIER setting, which is multiplied
by the number of pool slots (threads/processes/greenthreads).
- describes a function that can be interrupted in the middle of
execution (e.g. by hardware interrupt or signal) and then safely
called again later. Reentrancy is not the same as
idempotence as the return value does not have to
be the same given the same inputs, and a reentrant function may have
side effects as long as it can be interrupted; An idempotent function
is always reentrant, but the reverse may not be true.
- Task messages are converted to requests within the worker.
The request information is also available as the task’s
context (the task.request attribute).