[rabbitmq-discuss] Publish on a queue, then Monitor on a reply queue, with only 1 connection to the RabbitMQ server? Non-blocking?

[Christopher Lefevre]

Further research and testing yields that I would require using a blocking connection for that code to work. There isn't a .process_requests() in a synchronous SelectConnection.

Are there any examples for a non-blocking solution to having a simple app that sends a request, and then immediately monitors the reply_to queue for the response?

One other question that is more architecture based that I don't seem to have gotten the concept of, if you want to keep the number of connections to the server down per application instance, do you use multiple channels per connection for multiple queues? I attempted a solution wherein I would simply add a second channel to the connection, but that seemed to foul up the publish.


-Christopher Lefevre


-----Original Message-----
From: Marek Majkowski [mailto:majek04 at gmail.com]
Sent: Tuesday, September 06, 2011 12:43 PM
To: Christopher Lefevre
Cc: Michael Klishin; rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] Publish on a queue, then Monitor on a reply queue, with only 1 connection to the RabbitMQ server? Non-blocking?

On Tue, Sep 6, 2011 at 17:19, Christopher Lefevre
<CLefevre at transparent.com> wrote:
> To note, if this is an easier description, I’m trying to implement the RPC
> example on the RabbitMQ tutorial with a synchronous connection. Which I’ve
> copied below so you guys don’t need to go find it. However, the main impetus
> to me moving forward is lines 13/14:
>
>         result = self.channel.queue_declare(exclusive=True)
>
>         self.callback_queue = result.method.queue

Synchronous methods in AMQP return data. This data is captured
under 'result.method'.
result.method.queue contains a fresh, unique, exclusive queue name
that was just created.

> Line 13 declares the result variable as the product of the channel getting
> an exclusive queue created, which I get. However the part that I get caught
> up in is where the callback is set to result.method.queue in line 14. What
> exactly is the method.queue of the result object?

If you're interested in other fields under 'result.method' please take a look
at amqp spec, for example results of queue-declare are under queue-declare-ok
method: http://www.rabbitmq.com/amqp-0-9-1-reference.html#queue.declare-ok

> I am hoping to simply
> modify my Monitor/Publish classes to be able to have a synchronous
> publish/monitor without creating 2 connections. My current attempt at simply
> using one connection with 2 channels does not seem to be operating how I
> expected.

The problem is that RPC client does only listen for messages when
there is an RPC call running. So, you won't be able to get 'realtime'
data from other things that are hanging on the same connection.
You may hear the results only during the rpc call.

Cheers,
  Marek
The information contained in this electronic message and any attached document(s) is intended only for the personal and confidential use of the designated recipients named above. This message may be confidential. If the reader of this message is not the intended recipient, you are hereby notified that you have received this document in error, and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify sender immediately by telephone (603) 262-6300 or by electronic mail immediately. Thank you.