[rabbitmq-discuss] RabbitMQ/AMQP understanding

[Torben Hoffmann]

On Fri, Aug 22, 2008 at 5:39 PM, Holger Hoffstätte <holger at wizards.de>wrote:

> On 8/22/08, Ben Hood <0x6e6562 at gmail.com> wrote:
> >  >    2. Is there a way to notify clients like B and C that there is a
> message
> >  > for them in one of their queues? Or do you have to poll the queue to
> find
> >  > out if there is something for you? (Basically this is a question of
> using a
> >  > interrupt like thing vs polling.)
> >
> > If a client subscribes to a queue, the channel will deliver messages
> >  to it as and when they are routed, so there is no need to poll
> >  explicitly. If for some reason you need to poll, there is a method
> >  called basic.get which allows you to poll a queue.
> >
> >  BTW, are you asking this question in the context of the API of a MOM
> >  system that you have used in the past?
>
> I was wondering the same - to me it sounds like he might be looking
> for the equivalent of a JMS MessageListener (with delivery in a thread
> pool etc.) and I don't think that's something the Java client lib can
> do right now.
> Torben, can you clarify what language you are planning to use and
> whether this is what you meant with "polling vs. interrupt"?
>
> Holger
>

My plan is to use Erlang for the consumers since they have to deal with a
very concise protocol so pattern matching and bit strings is just what the
doctor ordered!

The specific behaviour I am looking for is that when a message arrives in a
queue that a consumer is tied to that message will be sent to the consumer
directly (this is what I meant by interrupt-like) instead of having to
program the consumer to look in the queue for a message ever so often to see
if there is something for it (this is what I meant by polling).

The reason I am asking this is two-fold:

   1. Polling with most likely slow down the system if I have a lot of
   consumers looking for a message ever so often. This will be bad since some
   of the message scenarios has the contraint that all members in a group must
   be able to receive data on a separate medium within 500 ms. This constraint
   applies to all sizes of our system - even nationwide systems - so time
   should not be wasted anywhere.
   2. I have just completed a project in Erlang where I was forced to set up
   a polling mechanism to get messages from an embedded server running on a
   communications card we had to use. I hated and still hate that solution
   since the polling is a fix to a problem that fits a more interrupt-like
   behaviour a lot better.

Hope this makes my constraints and desired solution a bit clearer.

Cheers,
Torben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080822/ad6ad103/attachment.htm