glossary.rst 4.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115
  1. .. _glossary:
  2. Glossary
  3. ========
  4. .. glossary::
  5. :sorted:
  6. acknowledged
  7. Workers acknowledge messages to signify that a message has been
  8. handled. Failing to acknowledge a message
  9. will cause the message to be redelivered. Exactly when a
  10. transaction is considered a failure varies by transport. In AMQP the
  11. transaction fails when the connection/channel is closed (or lost),
  12. but in Redis/SQS the transaction times out after a configurable amount
  13. of time (the ``visibility_timeout``).
  14. ack
  15. Short for :term:`acknowledged`.
  16. early acknowledgment
  17. Task is :term:`acknowledged` just-in-time before being executed,
  18. meaning the task won't be redelivered to another worker if the
  19. machine loses power, or the worker instance is abruptly killed,
  20. mid-execution.
  21. Configured using :setting:`task_acks_late`.
  22. late acknowledgment
  23. Task is :term:`acknowledged` after execution (both if successful, or
  24. if the task is raising an error), which means the task will be
  25. redelivered to another worker in the event of the machine losing
  26. power, or the worker instance being killed mid-execution.
  27. Configured using :setting:`task_acks_late`.
  28. early ack
  29. Short for :term:`early acknowledgment`
  30. late ack
  31. Short for :term:`late acknowledgment`
  32. ETA
  33. "Estimated Time of Arrival", in Celery and Google Task Queue, etc.,
  34. used as the term for a delayed message that should not be processed
  35. until the specified ETA time. See :ref:`calling-eta`.
  36. request
  37. Task messages are converted to *requests* within the worker.
  38. The request information is also available as the task's
  39. :term:`context` (the ``task.request`` attribute).
  40. calling
  41. Sends a task message so that the task function is
  42. :term:`executed <executing>` by a worker.
  43. kombu
  44. Python messaging library used by Celery to send and receive messages.
  45. billiard
  46. Fork of the Python multiprocessing library containing improvements
  47. required by Celery.
  48. executing
  49. Workers *execute* task :term:`requests <request>`.
  50. apply
  51. Originally a synonym to :term:`call <calling>` but used to signify
  52. that a function is executed by the current process.
  53. context
  54. The context of a task contains information like the id of the task,
  55. it's arguments and what queue it was delivered to.
  56. It can be accessed as the tasks ``request`` attribute.
  57. See :ref:`task-request-info`
  58. idempotent
  59. Idempotence is a mathematical property that describes a function that
  60. can be called multiple times without changing the result.
  61. Practically it means that a function can be repeated many times without
  62. unintended effects, but not necessarily side-effect free in the pure
  63. sense (compare to :term:`nullipotent`).
  64. Further reading: https://en.wikipedia.org/wiki/Idempotent
  65. nullipotent
  66. describes a function that'll have the same effect, and give the same
  67. result, even if called zero or multiple times (side-effect free).
  68. A stronger version of :term:`idempotent`.
  69. reentrant
  70. describes a function that can be interrupted in the middle of
  71. execution (e.g., by hardware interrupt or signal), and then safely
  72. called again later. Reentrancy isn't the same as
  73. :term:`idempotence <idempotent>` as the return value doesn't have to
  74. be the same given the same inputs, and a reentrant function may have
  75. side effects as long as it can be interrupted; An idempotent function
  76. is always reentrant, but the reverse may not be true.
  77. cipater
  78. Celery release 3.1 named after song by Autechre
  79. (http://www.youtube.com/watch?v=OHsaqUr_33Y)
  80. prefetch multiplier
  81. The :term:`prefetch count` is configured by using the
  82. :setting:`worker_prefetch_multiplier` setting, which is multiplied
  83. by the number of pool slots (threads/processes/greenthreads).
  84. `prefetch count`
  85. Maximum number of unacknowledged messages a consumer can hold and if
  86. exceeded the transport shouldn't deliver any more messages to that
  87. consumer. See :ref:`optimizing-prefetch-limit`.
  88. pidbox
  89. A process mailbox, used to implement remote control commands.