[rabbitmq-discuss] Erlang Client Example Code

[Glenn Rempe]

On Thu, Feb 25, 2010 at 11:18 PM, Ben Hood <0x6e6562 at gmail.com> wrote:
> Glenn,
>
> 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.
>>
>> http://github.com/grempe/rabbitmq-erlang-client-examples
>
> That looks a look terser :-)

Great.

>
> 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;

I'll look at making those changes.

>
>> 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.

Yes, it would be more effort.  I don't think I'll be taking that on at
the moment.  :-)


> 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.

That's great.  However please link to 'careo's github repo.  I forked
his and he has been pulling my changes in.  My intention in doing this
was both to aid in my own learning, as well as to provide at least one
working version of code for the community to look at.  I think I've
accomplished that.  Hopefully others will find it helpful.

http://github.com/careo/rabbitmq-erlang-client-examples

>
>> 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.

Thanks.  I was a bit surprised of the limitations of the direct
client.  Being an Erlang noob I was naively hoping that it would allow
me to take advantage of the distributed nature of Erlang nodes to
communicate with a rabbit instance anywhere in the distributed erlang
node cloud.  That would be nice.  ;-)  I think I'll probably have to
use the network client despite its additional overhead.

I'm surprised too that the Erlang client isn't a first class supported
client.  I saw the same thing working with the CouchDB team even
though you've both created excellent 'poster children' applications
for Erlang.  That's too bad.  :-(

Cheers and thanks for the look at the code.

Glenn