| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163 | 
							- .. _broker-sqs:
 
- ==================
 
-  Using Amazon SQS
 
- ==================
 
- .. admonition:: Experimental Status
 
-     The SQS transport is in need of improvements in many areas and there
 
-     are several open bugs.  Sadly we don't have the resources or funds
 
-     required to improve the situation, so we're looking for contributors
 
-     and partners willing to help.
 
- .. _broker-sqs-installation:
 
- Installation
 
- ============
 
- For the Amazon SQS support you have to install the `boto`_ library:
 
- .. code-block:: bash
 
-     $ pip install -U boto
 
- .. _boto:
 
-     http://pypi.python.org/pypi/boto
 
- .. _broker-sqs-configuration:
 
- Configuration
 
- =============
 
- You have to specify SQS in the broker URL::
 
-     BROKER_URL = 'sqs://ABCDEFGHIJKLMNOPQRST:ZYXK7NiynGlTogH8Nj+P9nlE73sq3@'
 
- where the URL format is::
 
-     sqs://aws_access_key_id:aws_secret_access_key@
 
- you must *remember to include the "@" at the end*.
 
- The login credentials can also be set using the environment variables
 
- :envvar:`AWS_ACCESS_KEY_ID` and :envvar:`AWS_SECRET_ACCESS_KEY`,
 
- in that case the broker url may only be ``sqs://``.
 
- .. note::
 
-     If you specify AWS credentials in the broker URL, then please keep in mind
 
-     that the secret access key may contain unsafe characters that needs to be
 
-     URL encoded.
 
- Options
 
- =======
 
- Region
 
- ------
 
- The default region is ``us-east-1`` but you can select another region
 
- by configuring the :setting:`BROKER_TRANSPORT_OPTIONS` setting::
 
-     BROKER_TRANSPORT_OPTIONS = {'region': 'eu-west-1'}
 
- .. seealso::
 
-     An overview of Amazon Web Services regions can be found here:
 
-         http://aws.amazon.com/about-aws/globalinfrastructure/
 
- Visibility Timeout
 
- ------------------
 
- The visibility timeout defines the number of seconds to wait
 
- for the worker to acknowledge the task before the message is redelivered
 
- to another worker.  Also see caveats below.
 
- This option is set via the :setting:`BROKER_TRANSPORT_OPTIONS` setting::
 
-     BROKER_TRANSPORT_OPTIONS = {'visibility_timeout': 3600}  # 1 hour.
 
- The default visibility timeout is 30 seconds.
 
- Polling Interval
 
- ----------------
 
- The polling interval decides the number of seconds to sleep between
 
- unsuccessful polls.  This value can be either an int or a float.
 
- By default the value is 1 second, which means that the worker will
 
- sleep for one second whenever there are no more messages to read.
 
- You should note that **more frequent polling is also more expensive, so increasing
 
- the polling interval can save you money**.
 
- The polling interval can be set via the :setting:`BROKER_TRANSPORT_OPTIONS`
 
- setting::
 
-     BROKER_TRANSPORT_OPTIONS = {'polling_interval': 0.3}
 
- Very frequent polling intervals can cause *busy loops*, which results in the
 
- worker using a lot of CPU time.  If you need sub-millisecond precision you
 
- should consider using another transport, like `RabbitMQ <broker-amqp>`,
 
- or `Redis <broker-redis>`.
 
- Queue Prefix
 
- ------------
 
- By default Celery will not assign any prefix to the queue names,
 
- If you have other services using SQS you can configure it do so
 
- using the :setting:`BROKER_TRANSPORT_OPTIONS` setting::
 
-     BROKER_TRANSPORT_OPTIONS = {'queue_name_prefix': 'celery-'}
 
- .. _sqs-caveats:
 
- Caveats
 
- =======
 
- - If a task is not acknowledged within the ``visibility_timeout``,
 
-   the task will be redelivered to another worker and executed.
 
-     This causes problems with ETA/countdown/retry tasks where the
 
-     time to execute exceeds the visibility timeout; in fact if that
 
-     happens it will be executed again, and again in a loop.
 
-     So you have to increase the visibility timeout to match
 
-     the time of the longest ETA you are planning to use.
 
-     Note that Celery will redeliver messages at worker shutdown,
 
-     so having a long visibility timeout will only delay the redelivery
 
-     of 'lost' tasks in the event of a power failure or forcefully terminated
 
-     workers.
 
-     Periodic tasks will not be affected by the visibility timeout,
 
-     as it is a concept separate from ETA/countdown.
 
-     The maximum visibility timeout supported by AWS as of this writing
 
-     is 12 hours (43200 seconds)::
 
-         BROKER_TRANSPORT_OPTIONS = {'visibility_timeout': 43200}
 
- - SQS does not yet support worker remote control commands.
 
- - SQS does not yet support events, and so cannot be used with
 
-   :program:`celery events`, :program:`celerymon` or the Django Admin
 
-   monitor.
 
- .. _sqs-results-configuration:
 
- Results
 
- -------
 
- Multiple products in the Amazon Web Services family could be a good candidate
 
- to store or publish results with, but there is no such result backend included
 
- at this point.
 
- .. warning::
 
-     Do not use the ``amqp`` backend with SQS.
 
-     It will create one queue for every task, and the queues will
 
-     not be collected.  This could cost you money that would be better
 
-     spent contributing an AWS result store backend back to Celery :)
 
 
  |