<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 10/05/11 11:01, Simone wrote:
    <blockquote
cite="mid:9673128.8763.1305021708674.JavaMail.geo-discussion-forums@vbjh33"
      type="cite">
      <div>Ok so I get publisher confirms have to do with messages
        getting from the publisher to the broker, while acks concern the
        link from the broker to the consumer, correct?</div>
      <div><br>
      </div>
      With strongest delivery warranty I mean to make sure that once a
      message has been published by a publisher it is going to reach all
      of the consumers supposed to be receiving it.
      <div><br>
      </div>
      <div>Therefore to achieve this sort of thing without using
        transactions I have to use both publisher confirms and consumer
        acks, right? Just trying to get a better understanding at how
        this works.</div>
    </blockquote>
    If you want a "once and only once" QoS, as opposed to a "at least
    once", then you'll need to deal with duplicates.<br>
    <br>
    If you use publisher acks, then, when you receive the publisher ack
    from the broker you know the message has reached the server ok.
    However, if the server crashes, then it's possible the message did
    reach the server ok, but you didn't get the ack back before the
    server died.<br>
    <br>
    If, on recovery, you resend any messages that you didn't receive
    publisher acks for, there is a possibility of duplicate messages on
    the server.<br>
    <br>
    Similarly with consuming messages, if you ack messages from the
    consumer once they have been consumed, then if the server crashes
    after a message has been consumed but before the ack for that
    message is processed on the server, on recovery of the server the
    message may be redelivered.<br>
    <br>
    if you build your message consumption logic to be idempotent (i.e.
    no harm comes in processing the same message twice), you can get an
    "effective" once and only once QoS. This may be hard or easy
    depending on your application semantics.<br>
    <blockquote
cite="mid:9673128.8763.1305021708674.JavaMail.geo-discussion-forums@vbjh33"
      type="cite">
      <div><br>
      </div>
      <div>Thanks</div>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
rabbitmq-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a>
<a class="moz-txt-link-freetext" href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>