More next steps

docs/getting-started/first-steps-with-celery.rst

@@ -45,8 +45,10 @@ There are several choices available, including:
 RabbitMQ
 --------
 
-`RabbitMQ`_ is feature-complete, stable, durable and easy to install. It's an excellent choice for a production environment. Detailed information about using RabbitMQ:
-    
+`RabbitMQ`_ is feature-complete, stable, durable and easy to install.
+It's an excellent choice for a production environment.
+Detailed information about using RabbitMQ with Celery:
+
     :ref:`broker-rabbitmq`
 
 .. _`RabbitMQ`: http://www.rabbitmq.com/
@@ -71,7 +73,7 @@ Redis
 
 `Redis`_ is also feature-complete, but is more susceptible to data loss in
 the event of abrupt termination or power failures. Detailed information about using Redis:
-    
+
     :ref:`broker-redis`
 
 .. _`Redis`: http://redis.io/
@@ -82,15 +84,14 @@ Using a database
 
 Using a database as a message queue is not recommended, but can be sufficient
 for very small installations.  Your options include:
-    
+
 * :ref:`broker-sqlalchemy`
 * :ref:`broker-django`
-* :ref:`broker-mongodb`
 
 If you're already using a Django database for example, using it as your
 message broker can be convenient while developing even if you use a more
 robust system in production.
-                         
+
 Other brokers
 -------------
 
@@ -98,6 +99,7 @@ In addition to the above, there are other transport implementations
 to choose from, including
 
 * :ref:`Amazon SQS <broker-sqs>`
+* :ref:`broker-mongodb`
 
 See also `Transport Comparison`_.
 
@@ -298,10 +300,10 @@ If you are configuring many settings at once you can use ``update``:
 For larger projects using a dedicated configuration module is useful,
 in fact you are discouraged from hard coding
 periodic task intervals and task routing options, as it is much
-better to keep this in a centralized location, and especially for libaries
+better to keep this in a centralized location, and especially for libraries
 it makes it possible for users to control how they want your tasks to behave,
-you can also imagine your sysadmin making simple changes to the configuration
-in the event of system trobule.
+you can also imagine your SysAdmin making simple changes to the configuration
+in the event of system trouble.
 
 You can tell your Celery instance to use a configuration module,
 by calling the :meth:`~@Celery.config_from_object` method:
@@ -328,7 +330,7 @@ current directory or on the Python path, it could look like this:
     CELERY_TIMEZONE = 'Europe/Oslo'
     CELERY_ENABLE_UTC = True
 
-To verify that your configuration file works properly, and does't
+To verify that your configuration file works properly, and doesn't
 contain any syntax errors, you can try to import it::
 
     $ python -m celeryconfig

docs/getting-started/introduction.rst

@@ -54,7 +54,7 @@ but there's also support for a myriad of other solutions, including
 using SQLite for local development.
 
 *Celery* can run on a single machine, on multiple machines, or even
-across datacenters.
+across data centers.
 
 Get Started
 ===========
@@ -69,15 +69,16 @@ getting started tutorials:
 Celery is…
 ==========
 
+.. _`mailing-list`: http://groups.google.com/group/celery-users
+
 .. topic:: \ 
 
     - **Simple**
 
-        Celery is easy to use and maintain, and does *not need configuration files*.
+        Celery is easy to use and maintain, and it *doesn't need configuration files*.
 
         It has an active, friendly community you can talk to for support,
-        including a :ref:`mailing-list <mailing-list>` and and :ref:`IRC
-        channel <irc-channel>`.
+        including a `mailing-list`_ and an :ref:`IRC channel <irc-channel>`.
 
         Here's one of the simplest applications you can make:
 
@@ -188,7 +189,7 @@ Features
         - **Autoreloading**
 
             In development workers can be configured to automatically reload source
-            code as it changes, including inotify support on Linux.
+            code as it changes, including :manpage:`inotify(7)` support on Linux.
 
             :ref:`Read more… <worker-autoreloading>`.
 
@@ -241,7 +242,7 @@ integration packages:
 
 The integration packages are not strictly necessary, but they can make
 development easier, and sometimes they add important hooks like closing
-database connections at ``fork``.
+database connections at :manpage:`fork(2)`.
 
 .. _`Django`: http://djangoproject.com/
 .. _`Pylons`: http://pylonshq.com/

docs/getting-started/next-steps.rst

@@ -8,6 +8,10 @@ The :ref:`first-steps` guide is intentionally minimal.  In this guide
 we will demonstrate what Celery offers in more detail, including
 how to add Celery support for your application and library.
 
+This document does not document all of Celery's features and
+best practices, so it's recommended that you also read the
+:ref:`User Guide <guide>`
+
 .. contents::
     :local:
     :depth: 1
@@ -502,3 +506,72 @@ give equal weight to the queues.
 
 To learn more about routing, including taking use of the full
 power of AMQP routing, see the :ref:`Routing Guide <guide-routing>`.
+
+Remote Control
+==============
+
+If you're using RabbitMQ (AMQP), Redis or MongoDB as the broker then
+you can control and inspect the worker at runtime.
+
+For example you can see what tasks the worker is currently working on::
+
+    $ celery -A proj inspect active
+
+This is implemented by using broadcast messaging, so all remote
+control commands are received by every worker in the cluster.
+
+You can also specify one or more workers to act on the request
+using the :option:`--destination` option, which is a comma separated
+list of worker hostnames::
+
+    $ celery -A proj inspect active --destination=worker1.example.com
+
+If a destination is not provided then every worker will act and reply
+to the request.
+
+The :program:`celery inspect` command contains commands that
+does not change anything in the worker, it only replies information
+and statistics about what is going on inside the worker.
+For a list of inspect commands you can execute::
+
+    $ celery -A proj inspect --help
+
+Then there is the :program:`celery control` command, which contains
+commands that actually changes things in the worker at runtime::
+
+    $ celery -A proj control --help
+
+For example you can force workers to enable event messages (used
+for monitoring tasks and workers)::
+
+    $ celery -A proj control enable_events
+
+When events are enabled you can then start the event dumper
+to see what the workers are doing::
+
+    $ celery -A proj events --dump
+
+or you can start the curses interface::
+
+    $ celery -A proj events
+
+when you're finished monitoring you can disable events again::
+
+    $ celery -A proj control disable_events
+
+The :program:`celery status` command also uses remote control commands
+and shows a list of online workers in the cluster::
+
+    $ celery -A proj status
+
+You can read more about the :program:`celery` command and monitoring
+in the :ref:`Monitoring Guide <guide-monitoring>`.
+
+
+What to do now?
+===============
+
+Now that you have read this document you should continue
+to the :ref:`User Guide <guide>`.
+
+There's also an :ref:`API reference <apiref>` if you are so inclined.

docs/userguide/application.rst

@@ -8,8 +8,8 @@
     :local:
     :depth: 1
 
-The Celery library must instantiated before use, and this instance
-is called the application.
+The Celery library must be instantiated before use, this instance
+is called an application (or *app* for short).
 
 The application is thread-safe so that multiple Celery applications
 with different configuration, components and tasks can co-exist in the
@@ -143,12 +143,10 @@ that are consulted in order:
     Go to the :ref:`Configuration reference <configuration>` for a complete
     listing of all the available settings, and their default values.
 
-
-
 ``config_from_object``
 ----------------------
 
-.. sidebar:: Timezones & Pytz.
+.. sidebar:: Timezones & pytz
 
     Setting a time zone other than UTC requires the :mod:`pytz` library
     to be installed, see the :setting:`CELERY_TIMEZONE` setting for more

docs/userguide/canvas.rst

@@ -207,7 +207,7 @@ The Primitives
         The map primitive works like the built-in ``map`` function, but creates
         a temporary task where a list of arguments is applied to the task.
         E.g. ``task.map([1, 2])`` results in a single task
-        being called, appyling the arguments in order to the task function so
+        being called, applying the arguments in order to the task function so
         that the result is::
 
             res = [task(1), task(2)]

docs/userguide/workers.rst

@@ -159,7 +159,7 @@ to the number of destination hosts.
     The solo and threads pool supports remote control commands,
     but any task executing will block any waiting control command,
     so it is of limited use if the worker is very busy.  In that
-    case you must increase the timeout waitin for replies in the client.
+    case you must increase the timeout waiting for replies in the client.
 
 .. _worker-broadcast-fun:
 
@@ -248,7 +248,7 @@ argument to :program:`celery worker` or the :setting:`CELERYD_STATE_DB`
 setting.
 
 Note that remote control commands must be working for revokes to work.
-Remote control commands are only supported by the amqp, redis and mongodb
+Remote control commands are only supported by the RabbitMQ (amqp), Redis and MongDB
 transports at this point.
 
 .. _worker-time-limits:
@@ -378,7 +378,7 @@ based on load:
     - and starts removing processes when the workload is low.
 
 It's enabled by the :option:`--autoscale` option, which needs two
-numbers: the maximum and minumum number of pool processes::
+numbers: the maximum and minimum number of pool processes::
 
         --autoscale=AUTOSCALE
              Enable autoscaling by providing