[rabbitmq-discuss] Multiple consumers

Matthias Radestock matthias at lshift.net
Mon Jul 9 16:56:26 BST 2007


Ben,

"Ben Hood" <0x6e6562 at gmail.com> writes:

>> Are you referring to the queue API that is used by the management
>> service? In that case, yes, in essence you have similar design
>> choices there on how to process the 'deliver' messages sent to the
>> native queue process. Be aware though that with this API you are
>> implementing a *queue*, not a *client*. So, for example, you end up
>> blocking the channel process through which the message was sent until
>> you return from the 'deliver' call.
>
> Thanks for pointing this out. When you say that, do you mean the
> defining a queue using the pseudo_queue method is implementing a queue
> rather than a client, e.g.
>
> Queue = rabbit_amqqueue:pseudo_queue(RealmName, QueueName, self())

Correct.

> Can I avoid this blocking by using the rabbit_amqqueue:basic_consume()
> method instead?

You could use a real queue instead of a pseudo queue, and, yes, then you
can use rabbit_amqqueue:basic_consume to consume messages. That requires
that your code implements the rabbit_writer message interface instead.

> Basically I have a remote consumers using the Java API and I have
> implemented business services in Erlang, which has the *luxury* of
> being able to call the API without having to frame methods and send
> stuff over a wire. So I think it quite good to just be able to use the
> asynchronous processing capabilities of the actual exchange.
> Furthermore, if use Erlang on the server side, I don't need to worry
> about concurrency issues and limitations that you would do in Java
> (please correct me if I'm wrong).

All sounds perfectly sensible.

>> Several people have asked whether there is an Erlang client for AMQP,
>> i.e. an Erlang API that implements the client portion of the
>> protocol. There currently isn't, but it is definitely something we'd
>> like to see developed. Contributions are welcome. Such a client would
>> present a relatively stable and interoperable API for Erlang code
>> wanting to use AMQP. It could also be designed in a way that allows the
>> framing to be bypassed when talking to RabbitMQ.
>
> Have you got any pointers as to how to go about this? I mean, would
> you just define
>
> a) The data structures as part of the interface spec (i.e. the
> rabbit.hrl header file)
> b) Methods to be exposed to client, e.g. openChannel0, openChannelN,
> accessRequest, basicConsume, basicPublish, etc
> c) Then implement these exported functions by sending the appropriate
> messages to the appropriate internal servers?

TBH, we haven't given this much thought yet. I have dug out a response
to an earlier email on the subject, sent before this list existed:

<quote>
If you want to build a proper AMQP client that implements the protocol
and is thus able to communicate with other AMQP-compliant brokers, you
have several options.

One approach would be to use our current framing code (auto-generated
from the protocol specification XML document) as the core, and refactor
the reader/writer state machines from rabbit_reader and rabbit_writer
into a generic AMQP peer library that could be used efficiently by both
a client and a broker implementation. This is most likely the approach
we will be taking.

Alternatively, you could build a fresh reader/writer state machine
specifically for client work. This would have the advantage of exposing
any AMQP-client-specific requirements that could then be refactored into
a common transport library at a later date.
</quote>

The above doesn't address the idea of bypassing the framing when the
Erlang client talks to RabbitMQ. I reckon that could be accomplished by
some further refactoring of reader/writer/channel, to separate out the
transport specific bits. We'll need to do that at some point anyway in
order to implement other transports, like SCTP.

One thing to be aware of is that this area of the code will be revised
quite heavily when we implement AMQP 0-10.


Regards,


Matthias.




More information about the rabbitmq-discuss mailing list