Hello,
I have a probably very simple problem that I can't seem to get working. I'm trying to get a SelectConnection to connect to RabbitMQ, publish a message on Queue1, and then monitor Queue2 on the same connection for the reply. The on_queue_declared function I'm using currently publishes the message to Queue1, then sets up a monitor on Queue2, but the message isn't getting picked up.

Though I also wanted it to be non-blocking so the website isn't stuck waiting for the reply, but rather can be updated as needed. Currently, I can get it to work if there is a pause, like when stepping through the program in a debugger, but when it runs without myself stepping through, it simply hangs when the queue is created and the message is never picked up.

Currently implementing this solution in Python.

Thank you for your time,
-Christopher Lefevre

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110906/c153caae/attachment.htm>

Search Discussions

  • Michael Klishin at Sep 6, 2011 at 1:38 pm
    2011/9/6 Christopher Lefevre <CLefevre at transparent.com>
    Though I also wanted it to be non-blocking so the website isn?t stuck
    waiting for the reply, but rather can be updated as needed. Currently, I can
    get it to work if there is a pause, like when stepping through the program
    in a debugger, but when it runs without myself stepping through, it simply
    hangs when the queue is created and the message is never picked up.

    Please post a code example that is at least similar to your actual code.
  • Christopher Lefevre at Sep 6, 2011 at 2:52 pm
    Here is the very basic publish, and then basic consume with a new queue.

    def _on_queue_declared(self, frame):
    self.StrReturn_Message = None

    self.channel.basic_publish(exchange='',
    routing_key=self.routing_key,
    body=self.message,
    properties = pika.BasicProperties(
    content_type=self.content_type,
    delivery_mode=self.delivery_mode,
    reply_to = self.reply_to,
    correlation_id = self.correlationID
    )
    )
    self.channel.basic_consume(self._return_stack, queue=self.reply_to)


    -Christopher Lefevre

    From: Michael Klishin [mailto:michael.s.klishin at gmail.com]
    Sent: Tuesday, September 06, 2011 9:38 AM
    To: Christopher Lefevre
    Cc: 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?

    2011/9/6 Christopher Lefevre <CLefevre at transparent.com<mailto:CLefevre at transparent.com>>
    Though I also wanted it to be non-blocking so the website isn?t stuck waiting for the reply, but rather can be updated as needed. Currently, I can get it to work if there is a pause, like when stepping through the program in a debugger, but when it runs without myself stepping through, it simply hangs when the queue is created and the message is never picked up.

    Please post a code example that is at least similar to your actual code.

    --
    MK

    http://github.com/michaelklishin
    http://twitter.com/michaelklishin
    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.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110906/47908329/attachment.htm>
  • Christopher Lefevre at Sep 6, 2011 at 4:19 pm
    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



    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? 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.

    #!/usr/bin/env python
    import pika
    import uuid

    class FibonacciRpcClient(object):
    def __init__(self):
    self.connection = pika.BlockingConnection(pika.ConnectionParameters(
    host='localhost'))

    self.channel = self.connection.channel()

    result = self.channel.queue_declare(exclusive=True)
    self.callback_queue = result.method.queue

    self.channel.basic_consume(self.on_response, no_ack=True,
    queue=self.callback_queue)

    def on_response(self, ch, method, props, body):
    if self.corr_id == props.correlation_id:
    self.response = body

    def call(self, n):
    self.response = None
    self.corr_id = str(uuid.uuid4())
    self.channel.basic_publish(exchange='',
    routing_key='rpc_queue',
    properties=pika.BasicProperties(
    reply_to = self.callback_queue,
    correlation_id = self.corr_id,
    ),
    body=str(n))
    while self.response is None:
    self.connection.process_data_events()
    return int(self.response)

    fibonacci_rpc = FibonacciRpcClient()

    print " [x] Requesting fib(30)"
    response = fibonacci_rpc.call(30)
    print " [.] Got %r" % (response,)



    -Christopher Lefevre

    From: Michael Klishin [mailto:michael.s.klishin at gmail.com]
    Sent: Tuesday, September 06, 2011 9:38 AM
    To: Christopher Lefevre
    Cc: 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?

    2011/9/6 Christopher Lefevre <CLefevre at transparent.com<mailto:CLefevre at transparent.com>>
    Though I also wanted it to be non-blocking so the website isn?t stuck waiting for the reply, but rather can be updated as needed. Currently, I can get it to work if there is a pause, like when stepping through the program in a debugger, but when it runs without myself stepping through, it simply hangs when the queue is created and the message is never picked up.

    Please post a code example that is at least similar to your actual code.

    --
    MK

    http://github.com/michaelklishin
    http://twitter.com/michaelklishin
    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.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110906/82f314be/attachment.htm>
  • Marek Majkowski at Sep 6, 2011 at 4:43 pm

    On Tue, Sep 6, 2011 at 17:19, Christopher Lefevre 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
  • Christopher Lefevre at Sep 6, 2011 at 5:46 pm
    We?re simply putting together a monitor that waits for a reply to be posted from a published item, so I would think that this should work out fine in that respect.

    So the idea is to Publish => Wait for reply on the reply_to queue, close the connection.

    Also thank you for the method explanation, reading up on the docs for that now.




    -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
    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.
  • Christopher Lefevre at Sep 6, 2011 at 7:05 pm
    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
    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.
  • Christopher Lefevre at Sep 7, 2011 at 1:21 pm
    Coming back to this after a day I realize throughout I was a bit off in describing my situation. I am actually attempting to get an asynchronous setup to work on one connection to the RabbitMQ server.

    Connect, create a channel(s), publish to a queue, then monitor on the reply queue, in an asynchronous state, returning the reply to a web page when completed.


    -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
    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.
  • Marek Majkowski at Sep 7, 2011 at 3:45 pm

    On Wed, Sep 7, 2011 at 14:21, Christopher Lefevre wrote:
    Coming back to this after a day I realize throughout I was a bit off in describing my situation. I am actually attempting to get an asynchronous setup to work on one connection to the RabbitMQ server.

    Connect, create a channel(s), publish to a queue, then monitor on the reply queue, in an asynchronous state, returning the reply to a web page when completed.
    Well, if you want to use asynchronous style, than you need to have
    an event loop and program using callbacks.

    Cheers,
    Marek
  • Christopher Lefevre at Sep 7, 2011 at 6:02 pm
    EXACTLY!

    That's the bit that I'm getting stuck on.

    I have a publish method that sets up a connection, then calls another function to open a channel, then publishes to the queue as shown previously.

    Within that function is a connection.ioloop.start() which I guess I don't really understand. For the individual publish/monitor functions they work as expected, the monitor will monitor and consume, while the publish only publishes once and breaks the ioloop, as expected.

    To get an asynchronous Publish, then Monitor the reply_to queue, I can instantiate the classes for the monitor/publisher I have, and it will work with 2 connections to the server. However trying to get this done with one connection is where I'm balking.

    -Christopher Lefevre


    -----Original Message-----
    From: Marek Majkowski [mailto:majek04 at gmail.com]
    Sent: Wednesday, September 07, 2011 11:45 AM
    To: Christopher Lefevre
    Cc: 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 Wed, Sep 7, 2011 at 14:21, Christopher Lefevre
    wrote:
    Coming back to this after a day I realize throughout I was a bit off in describing my situation. I am actually attempting to get an asynchronous setup to work on one connection to the RabbitMQ server.

    Connect, create a channel(s), publish to a queue, then monitor on the reply queue, in an asynchronous state, returning the reply to a web page when completed.
    Well, if you want to use asynchronous style, than you need to have
    an event loop and program using callbacks.

    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.
  • Gavin M. Roy at Sep 7, 2011 at 6:38 pm
    You can have multiple connections with one IO loop, assuming you're using PIka. In that case, the IOloop is a single instance across all connections, so you should setup both your connections before starting it, or use a timer to call a method after starting it that sets up your connections.

    Gavin

    On Wednesday, September 7, 2011 at 2:02 PM, Christopher Lefevre wrote:

    EXACTLY!

    That's the bit that I'm getting stuck on.

    I have a publish method that sets up a connection, then calls another function to open a channel, then publishes to the queue as shown previously.

    Within that function is a connection.ioloop.start() which I guess I don't really understand. For the individual publish/monitor functions they work as expected, the monitor will monitor and consume, while the publish only publishes once and breaks the ioloop, as expected.

    To get an asynchronous Publish, then Monitor the reply_to queue, I can instantiate the classes for the monitor/publisher I have, and it will work with 2 connections to the server. However trying to get this done with one connection is where I'm balking.

    -Christopher Lefevre


    -----Original Message-----
    From: Marek Majkowski [mailto:majek04 at gmail.com]
    Sent: Wednesday, September 07, 2011 11:45 AM
    To: Christopher Lefevre
    Cc: rabbitmq-discuss at lists.rabbitmq.com (mailto: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 Wed, Sep 7, 2011 at 14:21, Christopher Lefevre
    (mailto:CLefevre at transparent.com)> wrote:
    Coming back to this after a day I realize throughout I was a bit off in describing my situation. I am actually attempting to get an asynchronous setup to work on one connection to the RabbitMQ server.

    Connect, create a channel(s), publish to a queue, then monitor on the reply queue, in an asynchronous state, returning the reply to a web page when completed.
    Well, if you want to use asynchronous style, than you need to have
    an event loop and program using callbacks.

    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.
    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com (mailto:rabbitmq-discuss at lists.rabbitmq.com)
    https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110907/195ec288/attachment.htm>
  • Christopher Lefevre at Sep 7, 2011 at 6:45 pm
    Only using one connection is the point of this modification.

    I already have a setup that does an asynchronous call that instantiates a Pika Publisher to publish a message to the queue, and a Pika Monitor to consume messages. However those each create their own connection and ioloops.

    Am I chasing my tail trying to get multiple channels created for a single connection? Then creating a queue on each channel, one to monitor, one to publish to?

    Or is there some other more elegant solution to this? Looking to keep the number of connections to RabbitMQ down on a per application basis.


    -Christopher Lefevre

    From: Gavin M. Roy [mailto:gmr at myyearbook.com]
    Sent: Wednesday, September 07, 2011 2:38 PM
    To: Christopher Lefevre
    Cc: Marek Majkowski; 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?

    You can have multiple connections with one IO loop, assuming you're using PIka. In that case, the IOloop is a single instance across all connections, so you should setup both your connections before starting it, or use a timer to call a method after starting it that sets up your connections.

    Gavin

    On Wednesday, September 7, 2011 at 2:02 PM, Christopher Lefevre wrote:
    EXACTLY!

    That's the bit that I'm getting stuck on.

    I have a publish method that sets up a connection, then calls another function to open a channel, then publishes to the queue as shown previously.

    Within that function is a connection.ioloop.start() which I guess I don't really understand. For the individual publish/monitor functions they work as expected, the monitor will monitor and consume, while the publish only publishes once and breaks the ioloop, as expected.

    To get an asynchronous Publish, then Monitor the reply_to queue, I can instantiate the classes for the monitor/publisher I have, and it will work with 2 connections to the server. However trying to get this done with one connection is where I'm balking.

    -Christopher Lefevre


    -----Original Message-----
    From: Marek Majkowski [mailto:majek04 at gmail.com]
    Sent: Wednesday, September 07, 2011 11:45 AM
    To: Christopher Lefevre
    Cc: rabbitmq-discuss at lists.rabbitmq.com<mailto: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 Wed, Sep 7, 2011 at 14:21, Christopher Lefevre
    <CLefevre at transparent.comwrote:

    Coming back to this after a day I realize throughout I was a bit off in describing my situation. I am actually attempting to get an asynchronous setup to work on one connection to the RabbitMQ server.

    Connect, create a channel(s), publish to a queue, then monitor on the reply queue, in an asynchronous state, returning the reply to a web page when completed.

    Well, if you want to use asynchronous style, than you need to have
    an event loop and program using callbacks.

    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.
    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com<mailto:rabbitmq-discuss at lists.rabbitmq.com>
    https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

    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.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110907/c41f2f88/attachment.htm>
  • Gavin M. Roy at Sep 7, 2011 at 7:46 pm

    On Wednesday, September 7, 2011 at 2:45 PM, Christopher Lefevre wrote:

    Only using one connection is the point of this modification.


    Oh that's easy then.
    I already have a setup that does an asynchronous call that instantiates a Pika Publisher to publish a message to the queue, and a Pika Monitor to consume messages. However those each create their own connection and ioloops.


    No need for that.
    Am I chasing my tail trying to get multiple channels created for a single connection? Then creating a queue on each channel, one to monitor, one to publish to?
    You don't need a channel per queue really, but it should be easy to create -- this is more pseudocode, but should get the spirit across:

    conn = FooConnection(on_connection_open)
    conn.ioloop.start()


    def on_connection_open(conn):
    conn.channel(on_channel_one_open)
    conn.channel(on_channel_two_open)

    def on_channel_one_open(channel):
    global channel_one
    channel_one = channel
    channel_one.create_queue(on_monitor_queue_created)


    def on_monitor_queue_created(frame)
    channel_one.basic_consume('routing_key', monitor_consumer_function)

    def on_channel_two_open(channel):
    global channel_two
    channel_two = channel

    for x in xrange(0, 10000):
    publish_consumer_function(x)

    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110907/4e010739/attachment.htm>
  • Christopher Lefevre at Sep 7, 2011 at 8:17 pm
    Thanks Gavin, that actually seems to be exactly what I had tried previously, but didn?t work correctly.

    Going to re-investigate that solution that I tried and see if I just missed something in there.

    One thing that I notice actually, is you?ve declared 2 globals, which I have implemented differently, the on_open function I have is defined as: def _on_channel_open(self, channel_, callback_=None):

    Which then assigned channel_ to self.channel

    When I implemented the change, I had self.channel, and self.monitor_channel. However everything else looks the same. Going to have to put all of that back in at this point to double check my work. I had reverted at this point to look into alternative solutions.


    -Christopher Lefevre

    From: Gavin M. Roy [mailto:gmr at myyearbook.com]
    Sent: Wednesday, September 07, 2011 3:46 PM
    To: Christopher Lefevre
    Cc: Marek Majkowski; 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 Wednesday, September 7, 2011 at 2:45 PM, Christopher Lefevre wrote:

    Only using one connection is the point of this modification.
    Oh that's easy then.

    I already have a setup that does an asynchronous call that instantiates a Pika Publisher to publish a message to the queue, and a Pika Monitor to consume messages. However those each create their own connection and ioloops.
    No need for that.
    Am I chasing my tail trying to get multiple channels created for a single connection? Then creating a queue on each channel, one to monitor, one to publish to?
    You don't need a channel per queue really, but it should be easy to create -- this is more pseudocode, but should get the spirit across:

    conn = FooConnection(on_connection_open)
    conn.ioloop.start()

    def on_connection_open(conn):
    conn.channel(on_channel_one_open)
    conn.channel(on_channel_two_open)

    def on_channel_one_open(channel):
    global channel_one
    channel_one = channel
    channel_one.create_queue(on_monitor_queue_created)

    def on_monitor_queue_created(frame)
    channel_one.basic_consume('routing_key', monitor_consumer_function)

    def on_channel_two_open(channel):
    global channel_two
    channel_two = channel
    for x in xrange(0, 10000):
    publish_consumer_function(x)

    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.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110907/0b060948/attachment.htm>
  • Christopher Lefevre at Sep 7, 2011 at 8:49 pm
    Well, it all works now, thanks!

    It apprears my previous implementation simply had some mix-up in the channels or something. I believe what it may have been is when I did the line for: channel.basic_qos(prefetch_count=1)

    I may have not actually used the proper channel name there and simply applied it to the same channel twice.


    -Christopher Lefevre

    From: Gavin M. Roy [mailto:gmr at myyearbook.com]
    Sent: Wednesday, September 07, 2011 3:46 PM
    To: Christopher Lefevre
    Cc: Marek Majkowski; 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 Wednesday, September 7, 2011 at 2:45 PM, Christopher Lefevre wrote:

    Only using one connection is the point of this modification.
    Oh that's easy then.

    I already have a setup that does an asynchronous call that instantiates a Pika Publisher to publish a message to the queue, and a Pika Monitor to consume messages. However those each create their own connection and ioloops.
    No need for that.
    Am I chasing my tail trying to get multiple channels created for a single connection? Then creating a queue on each channel, one to monitor, one to publish to?
    You don't need a channel per queue really, but it should be easy to create -- this is more pseudocode, but should get the spirit across:

    conn = FooConnection(on_connection_open)
    conn.ioloop.start()

    def on_connection_open(conn):
    conn.channel(on_channel_one_open)
    conn.channel(on_channel_two_open)

    def on_channel_one_open(channel):
    global channel_one
    channel_one = channel
    channel_one.create_queue(on_monitor_queue_created)

    def on_monitor_queue_created(frame)
    channel_one.basic_consume('routing_key', monitor_consumer_function)

    def on_channel_two_open(channel):
    global channel_two
    channel_two = channel
    for x in xrange(0, 10000):
    publish_consumer_function(x)

    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.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110907/2baa89c9/attachment.htm>

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedSep 6, '11 at 1:33p
activeSep 7, '11 at 8:49p
posts15
users4
websiterabbitmq.com
irc#rabbitmq

People

Translate

site design / logo © 2022 Grokbase