Anyone have time to take a few of these on?<div><br></div><div>I know they are not specifically on-topic (and a bit open-ended) but we are evaluating messaging solutions (and even discussing writing our own) so it would be a huge help to get some feedback. I'd be happy to provide more specifics if needed.<div>
<br></div><div>Thanks,<br><br><div class="gmail_quote">On Mon, Jan 3, 2011 at 3:13 PM, Bill Moseley <span dir="ltr"><<a href="mailto:moseley@hank.org">moseley@hank.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<div><br></div><div>I'm just starting out with RabbitMQ and trying to wrap my head around a few concepts. I apologize if I ask something that should be obvious or I missed in the docs and faq. I'm hoping someone can help with a few scenarios, and please point me to further reading as needed.</div>
<div><br></div><div>
I'm curious about use-cases that are not directly related to RabbitMQ, but how to best use RabbitMQ in an web application's architecture. Thes are probably very common situations.</div><div><br></div><div>1) Notification of job status and completion: If the web app produces a request to generate an expensive PDF is there a common approach to detecting when the consumer is completed and the pdf is ready for downloading? Should I create a single-use return queue with x-expires and/or x-message-ttl on the queue? In a web app the web user may never come back to pick up the PDF.</div>
<div><br></div><div>2) Job sequencing: What's a common approach to multiple step processing that must be done serially? I.e. queue job "A" and when it's complete queue job "B". Doesn't really seem like consumer "A" should be responsible for submitting job "B". Is it better to create a consumer "AB" that submits "A" and waits for a message that "A" is complete and then submits job "B"?</div>
<div><br></div><div>3) Scheduling: I assume there's no facility for scheduling jobs to be delivered to consumers at some future time. Is there a better approach than using cron to check the database for jobs that should be queued based on time?</div>
<div><br></div><div>4) Cancel a request: We have some situations when a subsequent request should cancel processing of an earlier request. (Frankly, I think this is a design problem on our end.)</div><div><br></div><div>
5) Prevent duplicate job requests: In a web environment when things break problems often compound by users reloading requests that caused the problem in the first place. I'm not sure RabbitMQ would be involved at all in this scenario, but I'm asking just in case. ;) </div>
<div><br></div><div>Finally, it's great that RabbitMQ will send a message again if is is not ACK'd and a consumer closes its connection. But, is there any kind of max retry count available? That is, what's a good approach to prevent an errant job from killing all consumers one-by-one?</div>
<div><br></div><div>Thanks,</div><div><br></div><font color="#888888"><div>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org" target="_blank">moseley@hank.org</a><br>
</div>
</font></blockquote></div><br><br clear="all"><br>-- <br>Bill Moseley<br><a href="mailto:moseley@hank.org" target="_blank">moseley@hank.org</a><br>
</div></div>