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?

In addition, what does the following flags mean?
auto_delete
consumer_tag
no_local
no_ack


thank you.
Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20080317/70e5a901/attachment.htm

Search Discussions

  • Ben Hood at Mar 17, 2008 at 8:15 pm
    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
  • Ben Hood at Mar 17, 2008 at 8:50 pm
    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedMar 17, '08 at 4:53p
activeMar 17, '08 at 8:50p
posts3
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Ben Hood: 2 posts Joe lee: 1 post

People

Translate

site design / logo © 2022 Grokbase