[rabbitmq-discuss] Multiple consumers

[Ben Hood]

Matthias,

> No. The code base is fairly small, so it won't bee too much of a burden
> to carry forward any changes in this area. I just wanted to alert you to
> the fact that the APIs will definitely change.

Sorry, its taken a while but I've been otherwise busy. I've made a
first cut of an erlang client AMQP with the necessary changes in
rabbit_reader, rabbit_channel0 and rabbit_channel (see attached
patch).

This patch is not complete, but I wanted to submit it for a sanity
check before I go off down the garden path.

The change consists of

1. an amqp_client module, which exports a similar API to the Java API.
The implementation uses the rabbit native API sparingly, in fact, the
call to any concrete rabbit function could be a init parameter making
it totally rabbit agnostic at compile time. It sends AMQP methods as
standard erlang messages, but it could be further abstracted to be
able to add framing if one wanted to connect to a foreign AMQP server
via TCP (should the need arise). At the moment this also includes some
preprocessor definitions from rabbit.hrl and rabbit_framing.hrl, but
these are AMQP specific and could be refactored away as well.

2. Changes to the rabbit_reader, rabbit_channel0 and rabbit_channel
modules to bypass socket I/O and framing. I've tried to keep the
amount of code duplication to a bar minimum.

To use it you load amqp_client into the same VM as rabbit, then

1. amqp_client:start_link().
2. amqp_client:open_channel(1, "").
3. amqp_client:access_request(1, "/data/REALM_NAME").

And that's where I stopped before this sanity check, but I would go on
in the same vain with the rest of the protocol.

The amqp_client uses the gen_server behaviour so that it can maintain
protocol state as well as the state of channel pids, user creditials
and tickets.

Also, the error handling is still quite agricultural (exits need to be
trapped) and the client lifecycle needs some thought as well (e.g. how
to stop it cleanly).

Anyway, any suggestions would be greatly appreciated,

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: erlang_client_1.patch
Type: application/octet-stream
Size: 19242 bytes
Desc: not available
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20070719/24a97075/attachment.obj