[rabbitmq-discuss] Safely replaying archived messages from an external store

[Charles Duffy]

[Please pardon any duplicates -- cancelled an initial reply held for
moderation; sending this one as a subscriber].

On Wed, Oct 17, 2012 at 5:14 AM, Emile Joubert <emile at rabbitmq.com> wrote:

> You are correct that AMQP timestamps have 1sec resolution, but nothing
> prevents publishers from adding a custom header with greater resolution.
>
> There is a potential for messages to arrive inbetween retrieving
> messages from the database and normally consuming messages from the
> broker. Make sure you don't leave the door open for race conditions.
>

Thank you for your response.

I was under the impression, in generating the initial proposal, that the
second-resolution timestamp was provided by the AMQP server, not the client
-- being client-provided, I can't trust it for the same reason that I can't
trust a milisecond-resolution timestamp in a client-provided header.
Consequently, it's back to the drawing board there.

My current approach assumes that delivery order will be consistent across
clients. This seems to be required by the section of the AMQP spec reading "The
server MUST deliver messages of the same priority in order irrespective of
their individual persistence"; if this is the case, I can pull the first
message off the queue, find it in the database (polling until it exists),
and use the database insert ordering (as recorded by an AUTO_INCREMENT key)
to manage replay.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20121017/412042ba/attachment.htm>