[rabbitmq-discuss] Confirmation IDs

Nagy, Attila bra at fsn.hu
Sun Jul 27 19:59:58 BST 2014


On 07/27/14 16:25, Michael Klishin wrote:
> On 27 July 2014 at 15:54:44, Nagy, Attila (bra at fsn.hu) wrote:
>>> My case: I process a file, containing multiple records. I do
>> this in a
>> FIFO manner: reading the file from its head towards its tail,
>> sending
>> each record with AMQP and waiting for confirms.
>> The problem here is that I have to keep a local delivery tag to file
>> pointer table, so I know which delivery tag means which file pointer.
> Yes, you need to correlate messages with delivery tags.
Yeah, that's my problem. BTW, are confirmations guaranteed to be in the 
order the original messages have been submitted?
I can see no information about that, except the existence of multiple 
field, which I guess would be somewhat meaningless if the confirmations 
wouldn't be in original order.
>
>> I think it would be much easier and flexible if the confirmation
>> system
>> would allow data to be "inherited" from the original message,
>> like its
>> properties or headers.
> So, calculated from the message? That won't work very well if you publish
> exactly the same message N times in a row.
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.

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.
But STOMP is not really an option if you want to do serious things in 
RabbitMQ. :)

>
> Either way, it is probably too late to change how publisher confirms work
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)

Thanks,


More information about the rabbitmq-discuss mailing list