|
@@ -52,15 +52,43 @@ if it's able to find the task, or if some other error is happening.
|
|
|
Why won't my Periodic Task run?
|
|
|
-------------------------------
|
|
|
|
|
|
-See `Why won't my Task run?`_.
|
|
|
+**Answer:** See `Why won't my Task run?`_.
|
|
|
+
|
|
|
+How do I discard all waiting tasks?
|
|
|
+------------------------------------
|
|
|
+
|
|
|
+**Answer:** Use ``celery.task.discard_all()``, like this:
|
|
|
+
|
|
|
+ >>> from celery.task import discard_all
|
|
|
+ >>> discard_all()
|
|
|
+ 1753
|
|
|
+
|
|
|
+The number ``1753`` is the number of messages deleted.
|
|
|
+
|
|
|
+You can also start celeryd with the ``--discard`` argument which will
|
|
|
+accomplish the same thing.
|
|
|
+
|
|
|
+I've discarded messages, but there are still messages left in the queue?
|
|
|
+------------------------------------------------------------------------
|
|
|
+
|
|
|
+**Answer:** Tasks are acknowledged (removed from the queue) as soon
|
|
|
+as they are actually executed. After the worker has received a task, it will
|
|
|
+take some time until it is actually executed, especially if there are a lot
|
|
|
+of tasks already waiting for execution. Messages that are not acknowledged are
|
|
|
+hold on to by the worker until it closes the connection to the broker (AMQP
|
|
|
+server). When that connection is closed (e.g because the worker was stopped)
|
|
|
+the tasks will be re-sent by the broker to the next available worker (or the
|
|
|
+same worker when it has been restarted), so to properly purge the queue of
|
|
|
+waiting tasks you have to stop all the workers, and then discard the tasks
|
|
|
+using ``discard_all``.
|
|
|
|
|
|
Can I send some tasks to only some servers?
|
|
|
--------------------------------------------
|
|
|
|
|
|
-As of now there is only one use-case that works like this, and that is
|
|
|
-tasks of type ``A`` can be sent to servers ``x`` and ``y``, while tasks
|
|
|
-of type ``B`` can be sent to server ``z``. One server can't handle more than
|
|
|
-one routing_key, but this is coming in a later release.
|
|
|
+**Answer:** As of now there is only one use-case that works like this,
|
|
|
+and that is tasks of type ``A`` can be sent to servers ``x`` and ``y``,
|
|
|
+while tasks of type ``B`` can be sent to server ``z``. One server can't
|
|
|
+handle more than one routing_key, but this is coming in a later release.
|
|
|
|
|
|
Say you have two servers, ``x``, and ``y`` that handles regular tasks,
|
|
|
and one server ``z``, that only handles feed related tasks, you can use this
|
|
@@ -123,3 +151,4 @@ You can also override this using the ``routing_key`` argument to
|
|
|
>>> from myapp.tasks import RefreshFeedTask
|
|
|
>>> apply_async(RefreshFeedTask, args=["http://cnn.com/rss"],
|
|
|
... routing_key="feed.importer")
|
|
|
+
|