How to handle a NACK command (STOMP 1.1)

[gurkapa]

Hi guys, I've run into a some problems with a desgin decision while implementing STOMP 1.1. It's a new command introduced their that does not really have counterpart in the HornetQ core protocol. It's called NACK in this is the decription in the specification:

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.

NACK takes the same headers as ACK: message-id (mandatory), subscription (mandatory) andtransaction (OPTIONAL).

NACK applies either to one single message (if the subscription's ack mode is client-individual) or to all messages sent before and not yet ACK'ed or NACK'ed.

Any opinions on how you would like HornetQ to handle this? The full specification for STOMP 1.1 can be found here: http://stomp.github.com/stomp-specification-1.1.html in case you want to read more.

[clebert.suconic]

This is exactly what QueueImpl::cancel does.

If you look at ServerConsumerImpl::cancelRefs, you will see it cancelling every received reference, that method is called during close and rollback.

You would need to add a new method cancelRef(... don't know what parameter yet).

You would need to treat if the reference really belongs to the consumer. As you can't NACK a reference you didn't receive before.

[gurkapa]

Awesome, thanks!