<div><div>Agreed, and that's why I'm testing failure scenarios.</div><div><br></div><div>It would be nice to not to have to re-invent the wheel :-)</div><div><br></div><div>Isn't this a somewhat common use-case? A work queue filled with</div>
<div>tasks that can only be run once, running on real hardware which</div><div>means that at some point parts of the system WILL fail.</div><div><br></div><div>--</div><div>Robert Borkowski</div><div><br><div class="gmail_quote">
On Mon, Dec 14, 2009 at 5:34 PM, Benjamin Black <span dir="ltr"><<a href="mailto:b@b3k.us">b@b3k.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I apologize for not answering your Rabbit question. �What you are<br>
describing is why you need an application-layer notion of idempotence.<br>
It is at best frustrating and at worst dangerous to rely on a lower<br>
level component, especially one written by someone else without this<br>
exact use case in mind, to implement and enforce this sort of policy.<br>
<br>
<br>
Best of luck,<br>
b<br>
<div><div></div><div class="h5"><br>
On 12/14/09 2:13 PM, Robert Borkowski wrote:<br>
> Hi,<br>
><br>
> Can you please help me understand what is going on when I lose a member of a<br>
> cluster?<br>
> I'm seeing an odd behaviour that makes me worry. This queue is supposed to<br>
> hold<br>
> credit card transactions, so we _really_ want to avoid double-processing<br>
> messages.<br>
><br>
> Cluster consists of 2 members: (rabbit@mq1, rabbit@mq2).<br>
><br>
> 1) client connects to mq1, creates durable queue, pushes 100 persistent<br>
> messages in<br>
> � � root@mq1:~# rabbitmqctl list_queues<br>
> � � Listing queues ...<br>
> � � testqueue � � � 100<br>
> � � ...done.<br>
><br>
> 2) mq1 rabbitmq is stopped<br>
><br>
> 3) client connects to mq2, creates durable queue, pushes 100 persistent<br>
> messages in<br>
> � � root@mq2:~# rabbitmqctl list_queues<br>
> � � Listing queues ...<br>
> � � testqueue � � � 100<br>
> � � ...done.<br>
><br>
> 4) mq1 rabbitmq is started<br>
> � � root@mq2:~# rabbitmqctl list_queues<br>
> � � Listing queues ...<br>
> � � testqueue � � � 200<br>
> � � ...done.<br>
><br>
> 5) client drains the queue<br>
> � � rborkows@mq1:~/client/bunny$ ./bunny-subscriber<br>
> � � Drained 200 messages in 0.475371 seconds<br>
><br>
> 6) queue is now empty<br>
> � � root@mq2:~# rabbitmqctl list_queues<br>
> � � Listing queues ...<br>
> � � testqueue � � � 0<br>
> � � ...done.<br>
><br>
> 7) mq1 rabbitmq is restarted, 100 credit card transactions pop back into<br>
> existence, unhappy customers, etc.<br>
> � � root@mq1:~# /etc/init.d/rabbitmq-server restart<br>
> � � Restarting rabbitmq-server: SUCCESS<br>
> � � rabbitmq-server.<br>
> � � root@mq1:~# rabbitmqctl list_queues<br>
> � � Listing queues ...<br>
> � � testqueue � � � 100<br>
> � � ...done.<br>
><br>
> The expected behaviour is that after step 5 the messages are _gone_ from the<br>
> queue, never to be seen again.<br>
> What's going on here?<br>
><br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> rabbitmq-discuss mailing list<br>
> <a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
> <a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br>
<br>
<br>_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com">rabbitmq-discuss@lists.rabbitmq.com</a><br>
<a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
<br></blockquote></div><br>
</div></div>