[rabbitmq-discuss] Confirmation IDs

[Michael Klishin]

On 27 July 2014 at 23:01:12, Nagy, Attila (bra at fsn.hu) wrote:
> > Yeah, that's my problem. BTW, are confirmations guaranteed  
> to be in the
> order the original messages have been submitted?

Yes.

> Nope, from the record's identifier. I have an incoming task queue  
> (for
> example a file which is appended with records, or a database which  
> has
> rows), from which I can have a unique identifier which is always  
> available and can directly point to the record.
> So counting (because publish doesn't give it back) the sent messages  
> (and resetting the counter on reconnects) and maintaining
> counter->original message pointers are unnecessary indirections  
> to
> achieve this functionality.

Coming up with a good identifier for
an arbitrary message is much harder and there's no consensus on what's the best
way to do this.
Especially if you try to come up with a solution for multiple protocols.

> BTW, RabbitMQ's STOMP plugin does this, you can set a receipt  
> string and
> the message will be acknowledged back with that string, whatever  
> it is.

STOMP has this feature but AMQP 0-9-1 and MQTT do not, unfortunately.

> But STOMP is not really an option if you want to do serious things  
> in
> RabbitMQ. :)

I can't see why not.

> Isn't it possible to add additional info in the ACK frame without 
> breaking current clients?
> Or making it only appear when publish has a given pattern? (like  
> with STOMP)

For AMQP 0-9-1 clients, it is not. STOMP header values can be of arbitrary length and many
headers are optional. AMQP 0-9-1 methods have a fixed (mandatory) attributes
and only *some* have optional ones ("extra arguments", as an attribute table).
Unfortunately, basic.ack is not one of the latter group.
--  
MK  

Staff Software Engineer, Pivotal/RabbitMQ