From 277ef2af182dbdbcb49ee4022d79829dc1639ad9 Mon Sep 17 00:00:00 2001 From: Marek Majkowski Date: Tue, 5 Oct 2010 16:31:10 +0100 Subject: [PATCH] Python/1 tutorial tweaks. --- python/tutorial-one.md | 31 ++++++++++++++++++++++++++++--- python/tutorial-one.mdx | 36 ++++++++++++++++++++++++++++-------- 2 files changed, 56 insertions(+), 11 deletions(-) diff --git a/python/tutorial-one.md b/python/tutorial-one.md index cd4b0f5..4095039 100644 --- a/python/tutorial-one.md +++ b/python/tutorial-one.md @@ -73,7 +73,14 @@ RabbitMQ uses a weird jargon, but it's simple once you'll get it. For example: - * _A queue_ is the name for a mailbox. It lives inside RabbitMQ. + * _A queue_ is the name for a mailbox. It lives inside + RabbitMQ. Although messages flow through RabbitMQ and your + applications, they can be stored only inside a _queue_. A _queue_ + is not bound by any limits, it can store how many messages you + like - it's essentially an infinite buffer. Many _producers_ can send + messages that go to the one queue, many _consumers_ can try to + receive data from one _queue_. +
Dot graph @@ -170,8 +177,17 @@ _test_: -At that point we're ready to send a message. Our first message will contain -a string _Hello World!_. We are going to send it to our _test_ queue: +At that point we're ready to send a message. Our first message will +contain a string _Hello World!_ and we want to send it to our _test_ +queue. + +In RabbitMQ a message never goes directly to the queue, it always +needs to go through an _exchange_. But let's not get dragged by the +details - you can read more about _exchanges_ in third part of this +tutorial. All we need to know now is how to use a default exchange +identified by an empty string. That exchange is a special one that +allows us to specify exactly to which queue the message should go. +The queue name is specified by the `routing_key` variable: 
 9
 10
@@ -212,6 +228,12 @@ run the command as many times you like, and only one queue will be created.
+You may ask why to declare queue again - we have already declared it +in our previous code. We could have avoided that if we always run the +`send.py` program before this one. But we're not sure yet which +program to run as first. In such case it's a good practice to repeat +declaring the queue in both programs. + Receiving messages from the queue is a bit more complex. Whenever we receive a message, a `callback` function is called. In our case @@ -235,6 +257,9 @@ interested in messages from our _test_ queue:
+For that command to succeed we must be sure that a queue which we want +to subscribe to exists. Fortunately we're confident about that - we've +created a queue above - using `queue_declare`. And finally, we enter a never-ending loop that waits for data and runs callbacks whenever necessary. diff --git a/python/tutorial-one.mdx b/python/tutorial-one.mdx index f14b948..e56e928 100644 --- a/python/tutorial-one.mdx +++ b/python/tutorial-one.mdx @@ -76,7 +76,14 @@ RabbitMQ uses a weird jargon, but it's simple once you'll get it. For example: } {% enddot %} - * _A queue_ is the name for a mailbox. It lives inside RabbitMQ. + * _A queue_ is the name for a mailbox. It lives inside + RabbitMQ. Although messages flow through RabbitMQ and your + applications, they can be stored only inside a _queue_. A _queue_ + is not bound by any limits, it can store how many messages you + like - it's essentially an infinite buffer. Many _producers_ can send + messages that go to the one queue, many _consumers_ can try to + receive data from one _queue_. + {% dot -Gsize="10,0.3" -Grankdir=LR%} digraph G { @@ -183,18 +190,25 @@ _test_: {% highlight python linenos=true linenostart=8 %} - channel.queue_declare(queue='test') {% endhighlight %} -At that point we're ready to send a message. Our first message will contain -a string _Hello World!_. We are going to send it to our _test_ queue: +At that point we're ready to send a message. Our first message will +contain a string _Hello World!_ and we want to send it to our _test_ +queue. + +In RabbitMQ a message never goes directly to the queue, it always +needs to go through an _exchange_. But let's not get dragged by the +details - you can read more about _exchanges_ in third part of this +tutorial. All we need to know now is how to use a default exchange +identified by an empty string. That exchange is a special one that +allows us to specify exactly to which queue the message should go. +The queue name is specified by the `routing_key` variable: {% highlight python linenos=true linenostart=9 %} - channel.basic_publish(exchange='', routing_key='test', body='Hello World!') @@ -238,11 +252,16 @@ run the command as many times you like, and only one queue will be created. {% highlight python linenos=true linenostart=8 %} - channel.queue_declare(queue='test') {% endhighlight %} +You may ask why to declare queue again - we have already declared it +in our previous code. We could have avoided that if we always run the +`send.py` program before this one. But we're not sure yet which +program to run as first. In such case it's a good practice to repeat +declaring the queue in both programs. + Receiving messages from the queue is a bit more complex. Whenever we receive a message, a `callback` function is called. In our case @@ -250,7 +269,6 @@ this function will print on the screen the contents of the message. {% highlight python linenos=true linenostart=9 %} - def callback(ch, method, header, body): print " [x] Received %.20r" % (body,) @@ -262,13 +280,15 @@ interested in messages from our _test_ queue: {% highlight python linenos=true linenostart=11 %} - channel.basic_consume(callback, queue='test', no_ack=True) {% endhighlight %} +For that command to succeed we must be sure that a queue which we want +to subscribe to exists. Fortunately we're confident about that - we've +created a queue above - using `queue_declare`. And finally, we enter a never-ending loop that waits for data and runs callbacks whenever necessary.