[rabbitmq-discuss] Confirmation IDs
mklishin at gopivotal.com
Sun Jul 27 20:30:36 BST 2014
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?
> Nope, from the record's identifier. I have an incoming task queue
> example a file which is appended with records, or a database which
> 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
> 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
> 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.
Staff Software Engineer, Pivotal/RabbitMQ
More information about the rabbitmq-discuss