On 17 Mar 2008, at 16:53, joe lee wrote:
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
According RabbitMQ Java Client Documentation:
While a Channel can be used by multiple threads, it's important to
* that only one thread executes a command at once. Concurrent
* 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.
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
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