[rabbitmq-discuss] Consumer Callback
fangbot
fangbot at gmail.com
Tue Jul 26 22:27:15 BST 2011
Hi Steve,
Thanks for the response. After reviewing some other posts on this forum,
I've decided to use multithreading in order to achieve the behavior I'm
looking for. Essentially, for every consumer, I create a new thread and
inside the run() method, I am calling an infinite while loop in order to
automatically retrieve the results. All of this is just to familiarize
myself with how RabbitMQ works - in the future, I suspect that every client
will run on a different machine and thus there will be only two threads max
(the application thread and the consumer thread).
Another question - I am doing some performance testing on the messaging
speeds, and my tests are roughly modeled after those in MulticastMain.
However, I've noticed that to record the speeds, getTimeMillis() is being
used. However, if there are other threads (outside of my process) that are
also running, won't they throw off (i.e. increase) the recorded time since
getTimeMillis() isn't thread-specific? Shouldn't something like
ThreadMXBean.getCurrentThreadCPUTime() be used instead?
Thanks in advance for the response!
Best,
-Fang
Steve Powell-7 wrote:
>
> Dear fangbot,
> You do not say whether you are using Python or Java (the two languages
> shown on the tutorials pages) but I will assume it is Java.
>
>> is there a way to create an event
>> such that when a queue gets pushed a message, it automatically calls
>> consumer.nextDelivery somehow
>
>
> The simple answer is 'yes', approximately. There is a push interface
> (defined by the Consumer interface) which is driven whenever a message is
> delivered.
>
> The tutorials use QueueingConsumer, which is a way to isolate the clients
> engine (the channel thread) from the user's thread. As you observe, this
> is a pull interface. QueueingConsumer.nextDelivery() will block until
> there is a message to return.
>
> If you want to use a push interface (which is what QueueingConsumer uses
> under the covers) then you are free to create your own Consumer
> (implementation of the Consumer interface) class, and the handleDelivery()
> method therein will be driven when a message arrives. The drawback is
> that this 'callback' is driven on a RabbitMQ client thread, and (at the
> moment) you are not permitted to do long-running things on this thread or
> make channel calls, or block, as this will often result in deadlocks.
> However, if you can limit what this does, you are free to communicate with
> another thread of yours, for example to put it on a BlockingQueue (like
> QueueingConsumer does), or to otherwise trigger another thread to do
> something.
>
> The easiest (and recommended) way to code your own Consumer is to subclass
> DefaultConsumer, and override the methods you want to change (in your case
> handleDelivery()). Take a look at the DefaultConsumer class to see what it
> does.
>
> Other methods on the Consumer interface are driven if other events occur,
> like channel close, for example. Your class can then do the right thing.
>
> This area is currently being reworked -- not to change the interface
> (much!) but to lift some of the restrictions on the things a callback
> method can do without causing deadlocks -- which will also see better
> control of the system resources used by the consumer callbacks.
>
> I hope this helps -- please come back here if you have any more questions;
> or even if you don't -- we'd like to know how you get on.
>
> Steve Powell (a happy bunny)
> ----------some definitions from the SPD----------
> Rigatoni n. A prime-ministerial grin.
> Nigella n. The next bottle-size up from a Nebuchadnezzar.
> Homily adv. Rather like a frenchman.
>
> On 20 Jul 2011, at 23:26, fangbot wrote:
>
>>
>> I'm looking to create multiple publishers/subscribers from the main
>> thread
>> that my program is run (i.e. the thread where I have declared my
>> channel).
>> It seems that in the tutorials, the only way for consumers to get a
>> message
>> from the queue its connected to is to explicitly call
>> consumer.nextDelivery(). However, as far as my understanding, in order to
>> constantly check for new publications, this call must reside within a
>> while(true) loop.
>>
>> Say I wanted to create a consumer with an anonymous queue and attach it
>> to
>> an exchange. Then, I want to make a publication to that exchange. When
>> that
>> publication is made, the consumer will print something to the console
>> using
>> an overridden nextDelivery(). In order to do this, do I have to basically
>>
>> 1. Create the consumer/queue and attach it with a routingId to the
>> exchange
>> 2. Publish a method with that routingId to the exchange
>> 3. Invoke the while loop to constantly check for messages
>>
>> in that order?
>>
>> If so, then is there a way to support two (or more) consumers to
>> automatically get nextDelivery? It seems that the only way is to write a
>> while loop that goes through every consumer, and calls nextDelivery on
>> that
>> consumer, in an infinite loop. Instead, is there a way to create an event
>> such that when a queue gets pushed a message, it automatically calls
>> consumer.nextDelivery somehow?
>>
>> Thanks in advance for the reply. I'm fairly new to RabbitMQ, so please
>> forgive me if the question is somewhat basic/has already been answered
>> elsewhere :-D.
>> --
>> View this message in context:
>> http://old.nabble.com/Consumer-Callback-tp32103305p32103305.html
>> Sent from the RabbitMQ mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
--
View this message in context: http://old.nabble.com/Consumer-Callback-tp32103305p32143563.html
Sent from the RabbitMQ mailing list archive at Nabble.com.
More information about the rabbitmq-discuss
mailing list