|
@@ -24,10 +24,10 @@ Learn about;
|
|
|
|
|
|
Celery may seem daunting at first - but don't worry - this tutorial
|
|
|
will get you started in no time. It's deliberately kept simple, so
|
|
|
-to not confuse you with advanced features.
|
|
|
-After you have finished this tutorial
|
|
|
-it's a good idea to browse the rest of the documentation,
|
|
|
-for example the :ref:`next-steps` tutorial will
|
|
|
+as to not confuse you with advanced features.
|
|
|
+After you have finished this tutorial,
|
|
|
+it's a good idea to browse the rest of the documentation.
|
|
|
+For example the :ref:`next-steps` tutorial will
|
|
|
showcase Celery's capabilities.
|
|
|
|
|
|
.. contents::
|
|
@@ -61,10 +61,10 @@ command:
|
|
|
|
|
|
$ sudo apt-get install rabbitmq-server
|
|
|
|
|
|
-When the command completes the broker is already running in the background,
|
|
|
+When the command completes, the broker will already be running in the background,
|
|
|
ready to move messages for you: ``Starting rabbitmq-server: SUCCESS``.
|
|
|
|
|
|
-And don't worry if you're not running Ubuntu or Debian, you can go to this
|
|
|
+Don't worry if you're not running Ubuntu or Debian, you can go to this
|
|
|
website to find similarly simple installation instructions for other
|
|
|
platforms, including Microsoft Windows:
|
|
|
|
|
@@ -125,8 +125,8 @@ Let's create the file :file:`tasks.py`:
|
|
|
return x + y
|
|
|
|
|
|
The first argument to :class:`~celery.app.Celery` is the name of the current module.
|
|
|
-This is only needed to allow names to be generated automatically when the tasks are
|
|
|
-defined in the ``__main__`` module.
|
|
|
+This is only needed so that names can be automatically generated when the tasks are
|
|
|
+defined in the `__main__` module.
|
|
|
|
|
|
The second argument is the broker keyword argument, specifying the URL of the
|
|
|
message broker you want to use. Here using RabbitMQ (also the default option).
|
|
@@ -142,7 +142,7 @@ You defined a single task, called ``add``, returning the sum of two numbers.
|
|
|
Running the Celery worker server
|
|
|
================================
|
|
|
|
|
|
-You now run the worker by executing our program with the ``worker``
|
|
|
+You can now run the worker by executing our program with the ``worker``
|
|
|
argument:
|
|
|
|
|
|
.. code-block:: console
|
|
@@ -187,16 +187,16 @@ method that gives greater control of the task execution (see
|
|
|
>>> from tasks import add
|
|
|
>>> add.delay(4, 4)
|
|
|
|
|
|
-The task has now been processed by the worker you started earlier,
|
|
|
-and you can verify that by looking at the workers console output.
|
|
|
+The task has now been processed by the worker you started earlier.
|
|
|
+You can verify this by looking at the worker's console output.
|
|
|
|
|
|
-Calling a task returns an :class:`~@AsyncResult` instance:
|
|
|
-this can be used to check the state of the task, wait for the task to finish,
|
|
|
-or get its return value (or if the task failed, the exception and traceback).
|
|
|
+Calling a task returns an :class:`~@AsyncResult` instance.
|
|
|
+This can be used to check the state of the task, wait for the task to finish,
|
|
|
+or get its return value (or if the task failed, to get the exception and traceback).
|
|
|
|
|
|
-Results aren't enabled by default, so if you want to do RPC or keep track
|
|
|
-of task results in a database you have to configure Celery to use a result
|
|
|
-backend. This is described by the next section.
|
|
|
+Results are not enabled by default. In order to do remote procedure calls
|
|
|
+or keep track of task results in a database, you will need to configure Celery to use a result
|
|
|
+backend. This is described in the next section.
|
|
|
|
|
|
.. _celerytut-keeping-results:
|
|
|
|
|
@@ -265,13 +265,13 @@ the ``propagate`` argument:
|
|
|
>>> result.get(propagate=False)
|
|
|
|
|
|
|
|
|
-If the task raised an exception you can also gain access to the
|
|
|
+If the task raised an exception, you can also gain access to the
|
|
|
original traceback:
|
|
|
|
|
|
.. code-block:: pycon
|
|
|
|
|
|
>>> result.traceback
|
|
|
- …
|
|
|
+ …
|
|
|
|
|
|
See :mod:`celery.result` for the complete result object reference.
|
|
|
|
|
@@ -280,14 +280,14 @@ See :mod:`celery.result` for the complete result object reference.
|
|
|
Configuration
|
|
|
=============
|
|
|
|
|
|
-Celery, like a consumer appliance, doesn't need much to be operated.
|
|
|
-It has an input and an output, where you must connect the input to a broker and maybe
|
|
|
-the output to a result backend if so wanted. But if you look closely at the back
|
|
|
+Celery, like a consumer appliance, doesn't need much configuration to operate.
|
|
|
+It has an input and an output. The input must be connected to a broker, and the output can
|
|
|
+be optionally connected to a result backend. However, if you look closely at the back,
|
|
|
there's a lid revealing loads of sliders, dials, and buttons: this is the configuration.
|
|
|
|
|
|
-The default configuration should be good enough for most uses, but there are
|
|
|
-many things to tweak so Celery works just the way you want it to.
|
|
|
-Reading about the options available is a good idea to get familiar with what
|
|
|
+The default configuration should be good enough for most use cases, but there are
|
|
|
+many options that can be configured to make Celery work exactly as needed.
|
|
|
+Reading about the options available is a good idea to familiarize yourself with what
|
|
|
can be configured. You can read about the options in the
|
|
|
:ref:`configuration` reference.
|
|
|
|
|
@@ -312,15 +312,14 @@ If you're configuring many settings at once you can use ``update``:
|
|
|
enable_utc=True,
|
|
|
)
|
|
|
|
|
|
-For larger projects using a dedicated configuration module is useful,
|
|
|
-in fact you're discouraged from hard coding
|
|
|
-periodic task intervals and task routing options, as it's much
|
|
|
-better to keep this in a centralized location, and especially for libraries
|
|
|
-it makes it possible for users to control how they want your tasks to behave,
|
|
|
-you can also imagine your SysAdmin making simple changes to the configuration
|
|
|
+For larger projects, a dedicated configuration module is recommended.
|
|
|
+Hard coding periodic task intervals and task routing options is discouraged.
|
|
|
+It is much better to keep these in a centralized location. This is especially
|
|
|
+true for libraries, as it enables users to control how their tasks behave.
|
|
|
+A centralized configuration will also allow your SysAdmin to make simple changes
|
|
|
in the event of system trouble.
|
|
|
|
|
|
-You can tell your Celery instance to use a configuration module,
|
|
|
+You can tell your Celery instance to use a configuration module
|
|
|
by calling the :meth:`@config_from_object` method:
|
|
|
|
|
|
.. code-block:: python
|
|
@@ -330,8 +329,8 @@ by calling the :meth:`@config_from_object` method:
|
|
|
This module is often called "``celeryconfig``", but you can use any
|
|
|
module name.
|
|
|
|
|
|
-A module named ``celeryconfig.py`` must then be available to load from the
|
|
|
-current directory or on the Python path, it could look like this:
|
|
|
+In the above case, a module named ``celeryconfig.py`` must be available to load from the
|
|
|
+current directory or on the Python path. It could look something like this:
|
|
|
|
|
|
:file:`celeryconfig.py`:
|
|
|
|
|
@@ -346,7 +345,7 @@ current directory or on the Python path, it could look like this:
|
|
|
timezone = 'Europe/Oslo'
|
|
|
enable_utc = True
|
|
|
|
|
|
-To verify that your configuration file works properly, and doesn't
|
|
|
+To verify that your configuration file works properly and doesn't
|
|
|
contain any syntax errors, you can try to import it:
|
|
|
|
|
|
.. code-block:: console
|
|
@@ -390,7 +389,7 @@ for the task at runtime:
|
|
|
|
|
|
See :ref:`guide-routing` to read more about task routing,
|
|
|
and the :setting:`task_annotations` setting for more about annotations,
|
|
|
-or :ref:`guide-monitoring` for more about remote control commands,
|
|
|
+or :ref:`guide-monitoring` for more about remote control commands
|
|
|
and how to monitor what your workers are doing.
|
|
|
|
|
|
Where to go from here
|
|
@@ -398,7 +397,7 @@ Where to go from here
|
|
|
|
|
|
If you want to learn more you should continue to the
|
|
|
:ref:`Next Steps <next-steps>` tutorial, and after that you
|
|
|
-can study the :ref:`User Guide <guide>`.
|
|
|
+can read the :ref:`User Guide <guide>`.
|
|
|
|
|
|
.. _celerytut-troubleshooting:
|
|
|
|
|
@@ -426,16 +425,16 @@ Worker doesn't start: Permission Error
|
|
|
If you provide any of the :option:`--pidfile <celery worker --pidfile>`,
|
|
|
:option:`--logfile <celery worker --logfile>` or
|
|
|
:option:`--statedb <celery worker --statedb>` arguments, then you must
|
|
|
- make sure that they point to a file/directory that's writable and
|
|
|
+ make sure that they point to a file or directory that's writable and
|
|
|
readable by the user starting the worker.
|
|
|
|
|
|
Result backend doesn't work or tasks are always in ``PENDING`` state
|
|
|
--------------------------------------------------------------------
|
|
|
|
|
|
All tasks are :state:`PENDING` by default, so the state would've been
|
|
|
-better named "unknown". Celery doesn't update any state when a task
|
|
|
+better named "unknown". Celery doesn't update the state when a task
|
|
|
is sent, and any task with no history is assumed to be pending (you know
|
|
|
-the task id after all).
|
|
|
+the task id, after all).
|
|
|
|
|
|
1) Make sure that the task doesn't have ``ignore_result`` enabled.
|
|
|
|
|
@@ -447,9 +446,9 @@ the task id after all).
|
|
|
3) Make sure that you don't have any old workers still running.
|
|
|
|
|
|
It's easy to start multiple workers by accident, so make sure
|
|
|
- that the previous worker is properly shutdown before you start a new one.
|
|
|
+ that the previous worker is properly shut down before you start a new one.
|
|
|
|
|
|
- An old worker that aren't configured with the expected result backend
|
|
|
+ An old worker that isn't configured with the expected result backend
|
|
|
may be running and is hijacking the tasks.
|
|
|
|
|
|
The :option:`--pidfile <celery worker --pidfile>` argument can be set to
|
|
@@ -457,9 +456,9 @@ the task id after all).
|
|
|
|
|
|
4) Make sure the client is configured with the right backend.
|
|
|
|
|
|
- If for some reason the client is configured to use a different backend
|
|
|
- than the worker, you won't be able to receive the result,
|
|
|
- so make sure the backend is correct by inspecting it:
|
|
|
+ If, for some reason, the client is configured to use a different backend
|
|
|
+ than the worker, you won't be able to receive the result.
|
|
|
+ Make sure the backend is configured correctly:
|
|
|
|
|
|
.. code-block:: pycon
|
|
|
|