[rabbitmq-discuss] rabbitmq erlang client questions: channel access and flags

[Ben Hood]

Joe,


On 17 Mar 2008, at 16:53, joe lee wrote:

> Hi All,
>
> I was able to get erlang client and erlang rabbitmq server to work  
> successfully.  I have few questions about channel access by erlang  
> processes and certain flags in erlang client example that Ben  
> blogged about.
>
> According RabbitMQ Java Client Documentation:
> While a Channel can be used by multiple threads, it's important to  
> ensure
>  * that only one thread executes a command at once. Concurrent  
> execution of
>  * commands will likely cause an UnexpectedFrameError to be thrown.
>
> If you are using erlang client and that you spawn an erlang process  
> for each message(concurrently), does it mean you have to create new  
> channel/per erlang concurrent processes?

If I understand you correctly, you have a situation with one AMQP  
channel process and more than one user processes who want to use the  
same channel process.

This is possible albeit in a limited fashion, not because of the  
client side implementation, but because of the nature of the protocol.

Essentially,

1) Asynchronous AMQP methods can be sent concurrently;
2) Synchronous AMQP methods must be sent serially.

This is because there is no way to correlate the top and bottom halves  
of a synchronous invocation other than blocking concurrent access to  
the bottom half.

Concurrent access to a synchronous method is detected and an  
illegal_pending_rpc error is thrown. It may be an improvement on the  
library to include the Pid in the error statement.

Fortunately, those methods that you are most likely to want to use  
concurrently are actually asynchronous, i.e. publish and deliver.

The synchronous methods surround for the most part queue declaration,  
binding and general setup/teardown tasks.

These are the kind of things that you probably would not want or need  
to do concurrently.

Having said that, the exceptions to this are the consume and get  
methods.

In the case of consume methods, you could use the consumer_tag  
supplied by the user process to correlate across synchronous RPC  
halves, but you would have to lock on the tag wrt the amqp_channel (to  
allow it guarantee uniqueness), and which defeats the purpose of  
parallelization to a certain extent.

The same logic would theoretically apply to the get method, except  
that there is no tag in the method record to correlate on.

Hence the client's approach is quite simple: force the serialization  
of the synchronous methods.

User processes wanting to handle this situations more gracefully can  
trap this exit.

Please note that this is due to the protocol as opposed to the  
implementation.

HTH,

Ben