[rabbitmq-discuss] Erlang Client Example Code
0x6e6562 at gmail.com
Fri Feb 26 07:18:07 GMT 2010
On Fri, Feb 26, 2010 at 3:53 PM, Glenn Rempe <glenn at rempe.us> wrote:
> Thanks Ben. I've made your suggested changes, and I've sent Dane a
> pull request.
> You can take a look here.
That looks a look terser :-)
On second glance here a few more comments:
- In analogy to amqp_connection:close/1, there is also the shorter
amqp_channel:close/1 as well;
- It doesn't seem like you need to declare a specific queue name - you
could potentially use a server generated queue name if you'd like;
> It might be nice to figure out a way to pull these examples into the
> Erlang client codebase so others can see it without hunting.
Fair point. ATM we do have a programmers guide for the Erlang client
and generated API docs, but this is not on the RabbitMQ website
because the Erlang client is not a officially supported client yet. So
that may follow at some stage.
If you did decide to include say an examples directory into the core
client source tree, you'd need to create a patch against this and
submit that. Having said that, you'd need to make sure of the
following in order for the patch to be seriously considered:
- It would have to bind in the current Makefile, i.e. you'd need to
have a target to run all of the examples;
- The examples would have to be reasonably canonical and expressive in
nature. In your stocks example you'd need to delve in to the routing
key matching mechanics a little bit more. Though they can be
informative, I'm not sure that the code verbosity introduced by the
log statements is a good thing. You may want to ask on the list what
the intention of the amqp_dbg module is;
- You'd need to document them as well :-(
So it may be less effort on your part to remain separate from the core
client source tree, but that's down to you.
In the meantime, I'm sure that Alexis will link your github tree into
an appropriate space on the community part of the RabbitMQ website.
> I'm struggling a bit with how I can best make use of the direct client
> since it seems that it can only run on the same node as the RabbitMQ
> server process (and not across nodes). If I am mistaken please feel
> free to correct me. :-)
The motivation behind the direct client is to provide the AMQP library
semantics transparently to an application that is co-located on the
same node as the server. The advantage of this is that you don't incur
the network and marshalling overhead (having said this, I don't think
anybody has actually benchmarked this yet). This provides the
application with a non-Rabbit specific API but lets you embed this
directly into a running instance of Rabbit.
One example use case of this is the rabbit_shovel plugin, which can
take advantage of the colocation if you configure it to do so.
More information about the rabbitmq-discuss