text: Frequently Asked Questions¶
  - General
  - Misconceptions
  - Troubleshooting
  - MySQL is throwing deadlock errors, what can I do?
  - The worker isn]?
  - Django
  - Windows
  General¶
  What kinds of things should I use Celery for?¶
  Answer: Queue everything and delight everyone is a good article describing why you’d use a queue in a web context.
  These are some common use cases:
  - Running something in the background. For example, to finish the web request as soon as possible, then update the users page incrementally. This gives the user the impression of good performance and “snappiness”, even though the real work might actually take some time.
  - Running something after the web request has finished.
  - Making sure something is done, by executing it asynchronously and using retries.
  - Scheduling periodic work.
  And to some degree:
  - Distributed computing.
  - Parallel execution.
  Misconceptions¶
  Does Celery really consist of 50.000 lines of code?¶
  Answer: No, this and similarly large numbers have been reported at various locations.
  The numbers as of this writing are:
  - core: 7,141 lines of code.
  - tests: 14,209 lines.
  - backends, contrib, compat utilities: 9,032 lines.
  Lines of code isn’t a useful metric, so even if Celery did consist of 50k lines of code you wouldn’t be able to draw any conclusions from such a number.
  Does Celery have many dependencies?¶
  A common criticism is that Celery uses too many dependencies. The rationale behind such a fear is hard to imagine, especially considering code reuse as the established way to combat complexity in modern software development, and that the cost of adding dependencies is very low now that package managers like pip and PyPI makes the hassle of installing and maintaining dependencies a thing of the past.
  Celery has replaced several dependencies along the way, and the current list of dependencies are:
  celery¶
  Kombu is part of the Celery ecosystem and is the library used to send and receive messages. It’s also the library that enables us to support many different message brokers. It’s also used by the OpenStack project, and many others, validating the choice to separate it from the Celery code-base..le.
  You can set a global default serializer, the default serializer for a particular Task, or even what serializer to use when sending a single task instance.
  Is Celery for Django only?¶
  Answer: No, you can use Celery with any framework, web or otherwise.
  Do I have to use AMQP/RabbitMQ?¶
  Answer: No, although using RabbitMQ is recommended you can also use Redis,’t able to use AMQP, feel free to use these alternatives. They will probably work fine for most use cases, and note that the above points are not specific to Celery; If using Redis/database as a queue worked fine for you before, it probably will now. You can always upgrade later if you need to.
  Is Celery multilingual?¶
  Answer: Yes.
  worker is an implementation of Celery in Python. If the
  language has an AMQP client, there shouldn’t be much work to create a worker
  in your language. A Celery worker is just a program connecting to the broker
  to process messages.
  Also, there’s another way to be language-independent, and that tasks.
  Troubleshooting¶
  MySQL is throwing deadlock errors, what can I do?¶
  Answer: MySQL has default isolation level set to REPEATABLE-READ,
  if you don’t really need that, set it to READ-COMMITTED.
  You can do that by adding the following to your
  my.cnf:
  [mysqld] transaction-isolation = READ-COMMITTED
  For more information about InnoDB`s transaction model see MySQL - The InnoDB Transaction Model and Locking in the MySQL user manual.
  (Thanks to Honza Kral and Anton Tsigularov for this solution)
  The worker’s
  /var/log/rabbitmq/rabbit.log on
  most systems), it usually contains a message describing the reason.
  Does it work on FreeBSD?¶
  Answer: Depends;
  When using the RabbitMQ (AMQP) and Redis transports it should work out of the box.
  For other transports the compatibility prefork pool is used and requires a working POSIX semaphore implementation, this is enabled in FreeBSD by default since FreeBSD 8.x. For older version of FreeBSD, you have to enable POSIX semaphores in the kernel and manually recompile billiard.
  Luckily, Viktor Petersson has written a tutorial to get you started with Celery on FreeBSD here:
  I’m having IntegrityError: Duplicate Key errors. Why?¶
  Answer: See MySQL is throwing deadlock errors, what can I do?. Thanks to @@howsthedotcom.
  Why aren’t my tasks processed?¶
  Answer: With RabbitMQ you can see how many consumers are currently receiving tasks by running the following command:
  $ rabbitmqctl list_queues -p <myvhost> name messages consumers Listing queues ... celery 2891 2
  This shows that there’s 2891 messages waiting to be processed in the task queue, and there are two consumers processing them.
  One reason that the queue is never emptied could be that you have a stale worker process taking the messages hostage. This could happen if the worker wasn’t properly shut down.
  When a message is received by a worker the broker waits for it to be acknowledged before marking the message as processed. The broker won’t re-send that message to another consumer until the consumer is shut down properly.
  If you hit this problem you have to kill all workers manually and restart them:
  $ pkill 'celery worker' $ # - If you don't have pkill use: $ # ps auxww | grep 'celery worker' | awk ' | grep 'celery worker' | awk '{print $2}' | xargs kill -9
  Why won’t my Task run?¶
  Answer: There might be syntax errors preventing the tasks module being imported.
  You can find out if Celery is able to run the task by executing the task manually:
  >>> from myapp.tasks import MyPeriodicTask >>> MyPeriodicTask.delay()
  Watch the workers log file to see if it’s able to find the task, or if some other error is happening.
  Why won’t my periodic task run?¶
  Answer: See Why won’t my Task run?.
  How do I purge all waiting tasks?¶
  Answer: You can use the
  celery purge command to purge
  all configured task queues:
  $ celery -A proj purge
  or programmatically:
  >>> from proj.celery import app >>> app.control.purge() 1753
  If you only want to purge messages from a specific queue you have to use the AMQP API or the celery amqp utility:
  $ celery -A proj amqp queue.purge <queue name>
  The number 1753 is the number of messages deleted.
  You can also start’t acknowledged are
  held 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 purge the tasks
  using
  celery.control.purge().
  Results¶
  How do I get the result of a task if I have the ID that points there?¶
  Answer: Use task.AsyncResult:
  >>> result = my_task.AsyncResult(task_id) >>> result.get()
  This will give you a
  AsyncResult instance
  using the tasks current result backend.
  If you need to specify a custom result backend, or you want to use
  the current application’s default backend you can use
  app.AsyncResult:
  >>> result = app.AsyncResult(task_id) >>> result.get()
  Security¶
  Isn’t using pickle a security concern?¶
  Answer: also possible to add additional encryption and security to messages, if you have a need for this then you should contact the Mailing list.
  Is it safe to run celery worker as root?¶
  Answer: No!
  We’re not currently aware of any security issues, but it would be incredibly naive to assume that they don’t exist, so running the Celery services (celery worker, celery beat, celeryev, etc) as an unprivileged user is recommended.
  Brokers¶
  Why is RabbitMQ crashing?¶
  Answer: RabbitMQ will crash if it runs out of memory. This will be fixed in a future release of RabbitMQ. please refer to the RabbitMQ FAQ:
  Note
  This is no longer the case, RabbitMQ versions 2.0 and above includes a new persister, that’s tolerant to out of memory errors. RabbitMQ 2.1 or higher is recommended for Celery.
  If you’re still running an older version of RabbitMQ and experience crashes, then please upgrade!
  Misconfiguration of Celery can eventually lead to a crash on older version of RabbitMQ. Even if it doesn’t crash, this can still consume a lot of resources, so it’s important that you’re aware of the common pitfalls.
  - Events.
  Running
  worker with the
  -E
  option will send messages for events happening inside of the worker.
  Events should only be enabled if you have an active monitor consuming them, or if you purge the event queue periodically.
  - AMQP backend results.
  When running with the AMQP result backend, every task result will be sent as a message. If you don’t collect these results, they will build up and RabbitMQ will eventually run out of memory.’t supported when not using an AMQP broker?¶
  This is an incomplete list of features not available when using the virtual transports:
  - Remote control commands (supported only by Redis).
  - Monitoring with events may not work in all virtual transports.
  -
  - The header and fanout exchange types
  - (fanout is supported by Redis).
  Tasks¶
  How can I reuse the same connection when calling tasks?¶
  Answer: See the
  broker_pool_limit setting.
  The connection pool is enabled by default since version 2.5.
  sudo in a
  subprocess returns
  None¶
  There’t reject them they could be redelivered again and again, causing a loop.
  Recent versions of RabbitMQ has the ability to configure a dead-letter queue for exchange, so that rejected messages is moved there.
  Can I call a task by name?¶
  Answer: Yes, use
  app.send_task().
  You can also call a task by name, from any language,
  None.
  Can I specify a custom task_id?¶
  Answer: Yes, use the task_id argument to
  Task.apply_async():
  >>> task.apply_async(args, kwargs, task_id='…')
  Can I use decorators with tasks?¶
  Answer: Yes, but please see note in the sidebar at Basics.
  Can I use natural task ids?¶
  Answer: Yes, but make sure.
  A common pattern is to add callbacks to tasks:
  from celery.utils.log import get_task_logger logger = get_task_logger(__name__) @app.task def add(x, y): return x + y @app.task(ignore_result=True) def log_result(result): logger.info("log_result got: %r", result)
  Invocation:
  >>> (add.s(2, 2) | log_result.s()).delay()
  See Canvas: Designing Work.
  If you have more than one worker with the same host name, the control commands will be received in round-robin between them.
  To work around this you can explicitly set the nodename for every worker
  using the
  -n argument to
  worker:
  $ celery -A proj worker -n [email protected]%h $ celery -A proj worker -n [email protected]%h
  where
  %h.
  Can I change the interval of a periodic task at runtime?¶
  Answer: Yes, you can use the Django database scheduler, or you can
  create a new schedule subclass and override
  is_due():
  from celery.schedules import schedule class my_schedule(schedule): def is_due(self, last_run_at): return’s failed, but this is rarely the case. Imagine the following task:
  @app.task def process_upload(filename, tmpfile): # Increment a file count stored in a database increment_file_counter() add_file_metadata_to_db(filename, tmpfile) copy_file_to_destination(filename, tmpfile)
  If this crashed in the middle of copying the file to its destination the world would contain incomplete state. This isn’t a critical scenario of course, but you can probably imagine something far more sinister. So for ease of programming we have less reliability; It’s a good default, users who require it and know what they are doing can still enable acks_late (and in the future hopefully use manual acknowledgment).
  In addition Task.retry has features not available in AMQP transactions: delay between retries, max retries, etc.
  So use retry for Python errors, and if your task is idempotent combine that with acks_late if that level of reliability is required.
  Can I schedule tasks to execute at a specific time?¶
  Answer: Yes. You can use the eta argument of
  Task.apply_async(). of its child
  processes. You can direct a kill signal to a specific child process if
  you know the process is currently executing a task the worker shutdown
  is depending on, but this also means that a
  WorkerLostError state will
  be set for the task so the task.