[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