<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1429497656;
        mso-list-type:hybrid;
        mso-list-template-ids:-2038250068 67698713 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-number-format:alpha-lower;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body bgcolor=white lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hello again,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I’m working my way through several recovery scenarios. I think we’ve established the following:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>a.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If broker bounces, durable messages in the durable queue that have been consumed – but not acked – will be redelivered. <o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>b.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Such redelivered messages will have the “redelivered” flag set.<o:p></o:p></span></p><p class=MsoListParagraph style='text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style='mso-list:Ignore'>c.<span style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><![endif]><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If consumer bounces, both (a) and (b) still hold. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In re (a): is redelivery accomplished by placing another copy of the message in the queue (thus, two copies of same message are in the  queue – one consumed but not acked, the other brand new); OR does the broker simply know that it’s OK to redeliver the original message?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In re (b): the redelivered flag seems to enable the creation of what Hohpe calls an “idempotent receiver.” That is, the consumer can use this flag to decide how to dispose of the redelivered message. Consider a scenario wherein the consumers, all pulling from a single queue, dispatch the work to a lower layer service. If there are multiple consumer nodes (even multiple consumer threads), they will need some means of coordinating the disposition of the redelivered message. For example, NodeA consumes (but doesn’t ack) message 1. But it does dispatch the work represented by message 1 to a lower layer service. If the broker bounces and message 1 is redelivered, it might be consumed by NodeB. But the message 1 task is already in-flight on NodeA. So, depending on both the idempotency of the task and application specific functionality, NodeB might want to discard the redelivered message 1. Such intra-consumer/intra-consumer node coordination suggests that the first consumer of the message needs to record something, probably in the persistence layer, that says “I’ve started this particular task (using a unique request ID). Does this seem right?<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>In re (c): does redelivery after consumer bounce work because the broker detects the loss of connection?<br><br><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Please confirm, clarify, or correct as you see fit!<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks for your help.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>-Paul<o:p></o:p></span></p><p class=MsoNormal><a name="_MailEndCompose"><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></a></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> rabbitmq-discuss-bounces@lists.rabbitmq.com [mailto:rabbitmq-discuss-bounces@lists.rabbitmq.com] <b>On Behalf Of </b>Bell, Paul M.<br><b>Sent:</b> Saturday, January 21, 2012 5:39 PM<br><b>To:</b> Simone Busoli<br><b>Cc:</b> rabbitmq-discuss@lists.rabbitmq.com<br><b>Subject:</b> Re: [rabbitmq-discuss] Lack of Ack, Failure and Re-delivery<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><p class=MsoNormal>Thank you both.<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>-Paul<br><br>On Jan 21, 2012, at 5:24 PM, &quot;Simone Busoli&quot; &lt;<a href="mailto:simone.busoli@gmail.com">simone.busoli@gmail.com</a>&gt; wrote:<o:p></o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><p>Also in case 2 the broker will redeliver all messages that were not acked, although it doesn't necessarily mean that the consumer didn't really consume them already. For that you should look at the redelivered flag.<o:p></o:p></p><div><p class=MsoNormal>On Jan 21, 2012 11:20 PM, &quot;Bell, Paul M.&quot; &lt;<a href="mailto:pbell@syncsort.com">pbell@syncsort.com</a>&gt; wrote:<o:p></o:p></p><p class=MsoNormal>I apologize. I should have stated up front that the queues and messages are durable.<br><br>What happens in case 2, where the consumer bounces?<br><br>Thanks, Jason.<br><br>-Paul<br><br>________________________________________<br>From: Jason J. W. Williams [<a href="mailto:jasonjwwilliams@gmail.com">jasonjwwilliams@gmail.com</a>]<br>Sent: Saturday, January 21, 2012 5:05 PM<br>To: Bell, Paul M.<br>Cc: <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>Subject: Re: [rabbitmq-discuss] Lack of Ack, Failure and Re-delivery<br><br>Hi Paul,<br><br>If the messages were published with the durable flag and the queues are durable, the messages will survive the broker restart and be re-presented to consumers. If the messages or the queues were not durable they will disappear after restart.<br><br>-J<br><br>Sent via iPhone<br><br>Is your email Premiere?<br><br>On Jan 21, 2012, at 14:57, &quot;Bell, Paul M.&quot; &lt;<a href="mailto:pbell@syncsort.com">pbell@syncsort.com</a>&gt; wrote:<br><br>&gt; Hi,<br>&gt;<br>&gt; Suppose I have a producer on NodeP, a broker on NodeB, and a consumer on NodeC. Suppose further that explicit acks are required (i.e., if I've understood the docs, that &quot;noack&quot; is not in effect) and that after consuming a message from the queue, NodeC.consumer dispatches some other work in order to process that message. IOW: NodeC.consumer doesn't respond immediately with an ack.<br>&gt;<br>&gt; So, from NodeB.broker's point of view, the message has been moved from the exchange to the queue, consumed, but not yet ack-ed.<br>&gt;<br>&gt; What will happen under these two scenarios:<br>&gt;<br>&gt; 1. NodeB.broker bounces - when broker restarts what will he do with un-acked messages that have been delivered to queue and haven't been ack-ed; e.g., will these be again delivered to the queue?<br>&gt;<br>&gt;<br>&gt; 2. NodeC.consumer bounces - when consumer restarts is there any way he can again consume the un-acked message, and begin again the work that this message represents? (I suppose that NodeB.broker might be implicated here because it might detect the loss of connection to the NodeC.consumer....).<br>&gt;<br>&gt;<br>&gt; When I say &quot;bounces,&quot; I mean at a minimum that the application (broker, consumer) crashed and restarted. But I am also interested in the case where the node's OS is for whatever reason rebooted. Perhaps it looks no different.<br>&gt;<br>&gt; Thanks for your help.<br>&gt;<br>&gt; -Paul<br>&gt;<br>&gt;<br>&gt;<br>&gt; ATTENTION: -----<br>&gt;<br>&gt; The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other &nbsp;confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.<br>&gt; _______________________________________________<br>&gt; rabbitmq-discuss mailing list<br>&gt; <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>&gt; <a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>_______________________________________________<br>rabbitmq-discuss mailing list<br><a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br><a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><o:p></o:p></p></div></div></blockquote></div></body></html>