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>