<div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">[Please pardon any duplicates -- cancelled an initial reply held for moderation; sending this one as a subscriber].</span></div>
<div><br></div>On Wed, Oct 17, 2012 at 5:14 AM, Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You are correct that AMQP timestamps have 1sec resolution, but nothing<br>
prevents publishers from adding a custom header with greater resolution.<br>
<br>
There is a potential for messages to arrive inbetween retrieving<br>
messages from the database and normally consuming messages from the<br>
broker. Make sure you don't leave the door open for race conditions.<br></blockquote><span style="font-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)"><div class="gmail_quote">
<span style="font-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)"><br></span></div><div class="gmail_quote"><span style="font-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">Thank you for your response.</span></div>
<div class="gmail_quote"><span style="font-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)"><br></span></div>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.</span><div style="font-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">
<br></div><div style="font-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)">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 "<span style="line-height:18px;color:rgb(85,85,85);font-family:Verdana,sans-serif">The server MUST deliver messages of the same priority in order irrespective of their individual persistence</span>"; 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.</div>
</div>