Hello all,<br><br>I&#39;m investigating using RabbitMQ as a replacement for a few db-backed work queues.  Our replication master sees considerable bit of write traffic into these tables, and it would be nice to take that off of their hands.  My first attempt will be to replace our dirty users queue -- this stores a simple list of user ids, indicating for which users we need to do some background processing &amp; push out an updated user profile.  We mark many as &#39;dirty&#39; during the course of the day, and run several workers to update the profiles.  We usually have several hundred thousand users in the queue at a time.<br>


<br>This seems like a good fit for RabbitMQ, but I have a few questions/constraints:<br><br><ul><li>Our current system allows us to do a unique constraint on userid -- if someone is already in the dirty queue and dirties his or her profile again, we don&#39;t want to update it multiple times. We do an &#39;insert ignore&#39;, leaving us with at most one row per user.  Are there any clever ways to emulate this behavior?<br>

<br>I can think of a few ways to work around this outside of the queueing system, but all involve storing state elsewhere. I&#39;d love a native solution that would allow me to fire as many &quot;this user is dirty&quot; messages into the queue, but guarantee my workers that the message message I read from a queue encapsulates all previous dirtying events.  Perhaps this is a pipe dream.<br>
<br><br></li><li>Our workers like to leak memory, so we often find ourselves killing them ungracefully.  While missing a few dirty profiles isn&#39;t terrible, it would be nice premature worker death didn&#39;t have to cause this.  Along these lines, I&#39;m thinking we&#39;d receive the message, do work, and then ack recieipt of the message.  If we die before the ack, the message lives on and someone else will clean that profile later.<br>

<br>My question is about ack timing: how long does the worker have before the message is requeued? is this time configurable? is it configurable per queue?</li></ul><br>I&#39;m looking forward to hearing (er, reading) your thoughts.<br>
<br>-Brendan<br>