whatsnew-2.6.rst 7.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254
  1. .. _whatsnew-2.6:
  2. ==========================
  3. What's new in Celery 2.6
  4. ==========================
  5. Celery aims to be a flexible and reliable, best-of-breed solution
  6. to process vast amounts of messages in a distributed fashion, while
  7. providing operations with the tools to maintain such a system.
  8. Celery has a large and diverse community of users and contributors,
  9. you should come join us :ref:`on IRC <irc-channel>`
  10. or :ref:`our mailing-list <mailing-list>`.
  11. To read more about Celery you should visit our `website`_.
  12. While this version is backward compatible with previous versions
  13. it is important that you read the following section.
  14. If you use Celery in combination with Django you must also
  15. read the `django-celery changelog`_ and upgrade to `django-celery 2.6`_.
  16. This version is officially supported on CPython 2.5, 2.6, 2.7, 3.2 and 3.3,
  17. as well as PyPy and Jython.
  18. .. _`website`: http://celeryproject.org/
  19. .. _`django-celery changelog`: http://bit.ly/djcelery-26-changelog
  20. .. _`django-celery 2.5`: http://pypi.python.org/pypi/django-celery/
  21. .. contents::
  22. :local:
  23. .. _v260-important:
  24. Important Notes
  25. ===============
  26. * Task registry is no longer a global.
  27. * celery.task.Task is no longer bound to an app by default,
  28. so configuration of the task is lazy.
  29. * The @task decorator is now lazy when used with custom apps
  30. If ``accept_magic_kwargs`` is enabled (herby called "compat mode"), the task
  31. decorator executes inline like before, however for custom apps the @task
  32. decorator now returns a special PromiseProxy object that is only evaluated
  33. on access.
  34. All promises will be evaluated when `app.finalize` is called, or implicitly
  35. when the task registry is first used.
  36. * chain: Chain tasks together using callbacks under the hood.
  37. .. code-block:: python
  38. from celery import chain
  39. # (2 + 2) * 8 / 2
  40. res = chain(add.subtask((4, 4)),
  41. mul.subtask((8, )),
  42. div.subtask((2,))).apply_async()
  43. res.get() == 16
  44. res.parent.get() == 32
  45. res.parent.parent.get() == 4
  46. * The Celery instance can now be created with a broker URL
  47. .. code-block:: python
  48. celery = Celery(broker="redis://")
  49. * Result backends can now be set using an URL
  50. Currently only supported by redis. Example use::
  51. CELERY_RESULT_BACKEND = "redis://localhost/1"
  52. * Heartbeat frequency now every 5s, and frequency sent with event
  53. The heartbeat frequency is now available in the worker event messages,
  54. so that clients can decide when to consider workers offline based on
  55. this value.
  56. * Module celery.actors has been removed, and will be part of cl instead.
  57. * Introduces new ``celery`` command, which is an entrypoint for all other
  58. commands.
  59. The main for this command can be run by calling ``celery.start()``.
  60. * Tasks can now have callbacks and errbacks, and dependencies are recorded
  61. - The task message format have been updated with two new extension keys
  62. Both keys can be empty/undefined or a list of subtasks.
  63. - ``callbacks``
  64. Applied if the task exits successfully, with the result
  65. of the task as an argument.
  66. - ``errbacks``
  67. Applied if an error occurred while executing the task,
  68. with the uuid of the task as an argument. Since it may not be possible
  69. to serialize the exception instance, it passes the uuid of the task
  70. instead. The uuid can then be used to retrieve the exception and
  71. traceback of the task from the result backend.
  72. - ``link`` and ``link_error`` keyword arguments has been added
  73. to ``apply_async``.
  74. The value passed can be either a subtask or a list of
  75. subtasks:
  76. .. code-block:: python
  77. add.apply_async((2, 2), link=mul.subtask())
  78. add.apply_async((2, 2), link=[mul.subtask(), echo.subtask()])
  79. Example error callback:
  80. .. code-block:: python
  81. @task
  82. def error_handler(uuid):
  83. result = AsyncResult(uuid)
  84. exc = result.get(propagate=False)
  85. print("Task %r raised exception: %r\n%r" % (
  86. exc, result.traceback))
  87. >>> add.apply_async((2, 2), link_error=error_handler)
  88. - We now track what subtasks a task sends, and some result backends
  89. supports retrieving this information.
  90. - task.request.children
  91. Contains the result instances of the subtasks
  92. the currently executing task has applied.
  93. - AsyncResult.children
  94. Returns the tasks dependencies, as a list of
  95. ``AsyncResult``/``ResultSet`` instances.
  96. - AsyncResult.iterdeps
  97. Recursively iterates over the tasks dependencies,
  98. yielding `(parent, node)` tuples.
  99. Raises IncompleteStream if any of the dependencies
  100. has not returned yet.
  101. - AsyncResult.graph
  102. A ``DependencyGraph`` of the tasks dependencies.
  103. This can also be used to convert to dot format:
  104. .. code-block:: python
  105. with open("graph.dot") as fh:
  106. result.graph.to_dot(fh)
  107. which can than be used to produce an image::
  108. $ dot -Tpng graph.dot -o graph.png
  109. * Bugreport now available as a command and broadcast command
  110. - Get it from a Python repl::
  111. >>> import celery
  112. >>> print(celery.bugreport())
  113. - Use celeryctl::
  114. $ celeryctl report
  115. - Get it from remote workers::
  116. $ celeryctl inspect report
  117. * Module ``celery.log`` moved to :mod:`celery.app.log`.
  118. * Module ``celery.task.control`` moved to :mod:`celery.app.control`.
  119. * Adds :meth:`AsyncResult.get_leaf`
  120. Waits and returns the result of the leaf subtask.
  121. That is the last node found when traversing the graph,
  122. but this means that the graph can be 1-dimensional only (in effect
  123. a list).
  124. * Adds ``subtask.link(subtask)`` + ``subtask.link_error(subtask)``
  125. Shortcut to ``s.options.setdefault("link", []).append(subtask)``
  126. * Adds ``subtask.flatten_links()``
  127. Returns a flattened list of all dependencies (recursively)
  128. * ``AsyncResult.task_id`` renamed to ``AsyncResult.id``
  129. * ``TasksetResult.taskset_id`` renamed to ``.id``
  130. Internals
  131. ---------
  132. * Compat modules are now generated dynamically upon use.
  133. These modules are ``celery.messaging``, ``celery.log``,
  134. ``celery.decorators`` and ``celery.registry``.
  135. * :mod:`celery.utils` refactored into multiple modules:
  136. :mod:`celery.utils.text`
  137. :mod:`celery.utils.imports`
  138. :mod:`celery.utils.functional`
  139. * Now using :mod:`kombu.utils.encoding` instead of
  140. `:mod:`celery.utils.encoding`.
  141. * Renamed module ``celery.routes`` -> :mod:`celery.app.routes`.
  142. * Renamed package ``celery.db`` -> :mod:`celery.backends.database`.
  143. * Renamed module ``celery.abstract`` -> :mod:`celery.worker.abstract`.
  144. .. _v260-deprecations:
  145. Deprecations
  146. ============
  147. .. _v260-news:
  148. News
  149. ====
  150. In Other News
  151. -------------
  152. - Now depends on Kombu 2.1.4
  153. Fixes
  154. =====