<div>
<div>Often, a bit like threading, things can get split off, but later reconverge / reconvene / rejoin the same execution stream (e.g. do the resutls end up in a database / are they sent to the same end client)</div></div>
<div> </div>
<div>"idempotent" as mentioned is a very useful solution (i.e. the job could get done twice, but results/persistent state will look the same). You could implement that as reject 2nd duplicated worker results, or copy it in again, it doesn't matter. Assuming subsystems underneath the worker are transaction based (in the database sense), you can ensure nothing gets inconsistent. </div>
<div> </div>
<div>It took me a a few days to get comfortable with the "idempotent" idea, but now I think I can work that idea into most situations. The resulting code while not materially that different appears to me to be more complete, and thinking through an additional edge case, once you get used to it, in my opinion adds value and doesn't get in the way of the development process.</div>
<div> </div>
<div>-Steven<br></div>
<div class="gmail_quote">On 11 January 2011 15:21, Derek Chen-Becker <span dir="ltr"><<a href="mailto:dbecker@cpicorp.com">dbecker@cpicorp.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">On 01/10/2011 06:15 PM, Sami Samhuri wrote:<br>> Hi all,<br>><br>> I'm designing a small distributed system with some queueing involved and<br>> have some doubts that Rabbit is the right solution for parts of it.<br>
> Hoping that some of you can shed some light and let me know if Rabbit<br>> can do it all, which would be great, or if there's a better and/or<br>> simpler solution I've missed. I realize that Rabbit is for message<br>
> passing and is not a work queue, so perhaps I'm trying to shove a square<br>> peg into a round hole. If so please tell me that I'm barking up the<br>> wrong tree.<br><br></div>We use RabbitMQ for a render farm work queue and the way you deal with<br>
possible "lost" consumers is with ACKs. You need to turn off auto-ack<br>when you set up the consumer, and then after you process the message you<br>explicitly ACK it (BasicAck). If, for some reason, your client dies<br>
while in the middle of processing messages, any unacked messages it was<br>holding on to get re-inserted into the queue.<br><font color="#888888"><br>Derek<br></font>
<div>
<div></div>
<div class="h5">_______________________________________________<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" target="_blank">https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></div></blockquote></div><br>