I get an unexpected behaviour with STOMP & NACK with RabbitMQ 2.7.1.

Here is my test, using an empty queue.
- client1 connects, sends a message to the queue and disconnects
- client2 connects, subscribes to the queue with ack:client
- client2 receives the message (so far so good) but does not ack it
- client3 connects, subscribes to the queue
- client2 sends a NACK frame for the message
- client2 receives the message once more
- client3 receives nothing

I would have expected the other client (client3) to receive the
message that has not been consumed by client2. In fact, this is how
ActiveMQ and Apollo work.

FWIW, the STOMP 1.1 spec mentions:
NACK is the opposite of ACK. It is used to tell the server that the
client did not consume the message. The server can then either send
the message to a different client, discard it, or put it in a dead
letter queue. The exact behavior is server specific.
So, although the behavior is not strictly defined, re-sending the
message to the same client does not look appropriate to me.

What do you think?

Cheers,

Lionel

Search Discussions

  • Steve Powell at Feb 27, 2012 at 10:21 am
    Lionel,

    Apologies for the tardy reply.

    Thank you for reporting this. What is happening is that the NACK sets the
    'requeue=true' flag, which, by definition, puts the message back on its queue.
    It is then available for redelivery. Whether it gets redelivered to the same
    consumer depends on lots of things, but is entirely possible, and is expected
    when there is only one consumer.

    Currently, we expect this behaviour and did not think it was prohibited by the
    specification.

    If this is determined to violate the specification we could set requeue=false on
    NACK, then neither this client, nor any other, will see the message; which is
    allowable server behaviour. There is currently no mechanism for re-routing
    messages that are NACKd, but this may change in the near future.

    Steve Powell
    steve at rabbitmq.com
    [wrk: +44-2380-111-528] [mob: +44-7815-838-558]
    On 22 Feb 2012, at 12:24, Lionel Cons wrote:

    I get an unexpected behaviour with STOMP & NACK with RabbitMQ 2.7.1.

    Here is my test, using an empty queue.
    - client1 connects, sends a message to the queue and disconnects
    - client2 connects, subscribes to the queue with ack:client
    - client2 receives the message (so far so good) but does not ack it
    - client3 connects, subscribes to the queue
    - client2 sends a NACK frame for the message
    - client2 receives the message once more
    - client3 receives nothing

    I would have expected the other client (client3) to receive the
    message that has not been consumed by client2. In fact, this is how
    ActiveMQ and Apollo work.

    FWIW, the STOMP 1.1 spec mentions:
    NACK is the opposite of ACK. It is used to tell the server that the
    client did not consume the message. The server can then either send
    the message to a different client, discard it, or put it in a dead
    letter queue. The exact behavior is server specific.
    So, although the behavior is not strictly defined, re-sending the
    message to the same client does not look appropriate to me.

    What do you think?

    Cheers,

    Lionel
    _______________________________________________
    rabbitmq-discuss mailing list
    rabbitmq-discuss at lists.rabbitmq.com
    https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouprabbitmq-discuss @
categoriesrabbitmq
postedFeb 22, '12 at 12:24p
activeFeb 27, '12 at 10:21a
posts2
users2
websiterabbitmq.com
irc#rabbitmq

2 users in discussion

Lionel Cons: 1 post Steve Powell: 1 post

People

Translate

site design / logo © 2017 Grokbase