|
|
| Author |
Message |
< RabbitMQ mailing list ~ rabbitmq erlang client questions: channel access and flags |
| Guest |
 Posted: Mon Mar 17, 2008 4:53 pm |
 |
|
|
Guest
|
Hi All,
I was able to get erlang client and erlang rabbitmq server to work successfully. |
|
|
| Back to top |
|
| 0x6e6562 |
| Posted: Mon Mar 17, 2008 8:15 pm |
|
|
|
User
Joined: 12 Jul 2007
Posts: 250
|
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
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
 
|
| 0x6e6562 |
| Posted: Mon Mar 17, 2008 8:51 pm |
|
|
|
User
Joined: 12 Jul 2007
Posts: 250
|
Joe,
This is taken from the amqp0-8.xml.
On 17 Mar 2008, at 16:53, joe lee wrote:
> In addition, what does the following flags mean?
> auto_delete
auto-delete queue or exchange when unused
>
> consumer_tag
<domain name="consumer tag" type="shortstr">
consumer tag
<doc>
Identifier for the consumer, valid within the current connection.
</doc>
<rule implement="MUST">
The consumer tag is valid only within the channel from which the
consumer was created. I.e. a client MUST NOT create a consumer in
one channel and then use it in another.
</rule>
</domain>
>
> no_local
<domain name="no local" type="bit">
do not deliver own messages
<doc>
If the no-local field is set the server will not send messages to
the client that published them.
</doc>
</domain>
>
> no_ack
<domain name="no ack" type="bit">
no acknowledgement needed
<doc>
If this field is set the server does not expect acknowledgments
for messages. That is, when a message is delivered to the client
the server automatically and silently acknowledges it on behalf
of the client. This functionality increases performance but at
the cost of reliability. Messages can get lost if a client dies
before it can deliver them to the application.
</doc>
</domain>
HTH,
Ben
_______________________________________________
rabbitmq-discuss mailing list
rabbitmq-discuss@lists.rabbitmq.com
http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
