[rabbitmq-discuss] RabbitMQ erlang client documentation

[Sylvain Hellegouarch]

Vlad Alexandru Ionescu a écrit :
> Sylvain,
>
>> I think there is one of the test module which might need some updates 
>> then. 
> The tests work for us. They should work for you too. Type the 
> following while in the rabbitmq-erlang-client folder:
>
>  $ make all_tests
>
> (you should keep rabbitmq-server, rabbitmq-erlang-client and 
> rabbitmq-codegen in the same folder for this to work; do not start the 
> server for this, it is started by the tests).
> If the tests fail there's probably a problem with your copy. If you 
> post the output we may be able to help.

The tests are okay, it's one of the few comments within the test:

http://hg.rabbitmq.com/rabbitmq-erlang-client/file/179c76eb4087/test/test_util.erl#l49

Since that was one of the only spot where I could find documentation... 
well I thought to mention it wasn't correct :)

>
>> Should channels be on per process basis? Say I create a channel, can 
>> I publish more than once without having to wait for each ack? Or is 
>> there a sequential constraint so that the channel knows where to 
>> propagate the potential ack from the server
> You can use a channel from more than one process. The channel process 
> queues up the calls and sends them to the server one by one (sends 
> one, waits for reply, sends the next, waits for reply etc). While a 
> call is in the queue to be sent to the server, the (user) process 
> which initiated the call is blocked while the methods in front in the 
> queue are processed plus the time for our actual call.
> So the channel takes care of serializing the methods and remembers 
> which process sent which method so it can reply (return value) to user 
> processes accordingly.
> However, due to the synchronous nature of this mechanism, just one 
> channel will not utilize the entire bandwidth available (e.g. while 
> the channel is waiting for the reply, it does not send the next call). 
> For this reason, it is advisable to split tasks that have no relation 
> to each other (the order of the events does not matter between tasks) 
> so that they use separate channels.
>
> All the above applies to synchronous methods (like basic.get for 
> example).
> Asynchronous methods (like basic.publish) are not queued up. They are 
> sent immediately no matter what is in the queue (a call may end up 
> after a cast at the server even though the call was made before the 
> cast, if the call has to wait in line).
>
> You can use amqp_channel:call/{2,3} for both sync and async methods 
> (async methods return 'ok' immediately) and amqp_channel:cast/{2,3} 
> only for async methods.
>
>

Thanks that's really useful to know.

- Sylvain