title: is there a design pattern for an amqp architecture for commit/rollback message handling?
body: <p>I have a simple producer/consumer amqp set up like this:</p>
  
  <pre><code>producer -&gt; e1:jobs_queue -&gt; consumer -&gt; e2:results_queue -&gt; result_handler
  </code></pre>
  
  <p>The producer sends of some number of jobs. The consumer pulls down jobs one at a time, and processes them, pushing the result into another queue. These are then pulled out by the result_handler that publishes the results to a database.</p>
  
  <p>Sometimes the consumer fails - it may get killed by the OS or throw an exception. If this happens while it is processing a message then this message is lost, no corresponding result is produced and I am sad. I would be happy again if the failed job was re-queued.</p>
  
  <p>What I'm looking for is a design pattern for ensuring that either <em>consumer</em> processes the job to completion and puts a corresponding result into *results_queue*, or if it fails that the job is put back into *jobs_queue*. As <em>consumer</em> is what is failing, <em>consumer</em> should not be responsible for managing any messages relating to its own supervision.</p>
  
  <p>We know that <em>consumer</em> has failed to process a job if:</p>
  
  <ul>
  <li>it took a job from *job_queue* and no result has been produced after some timeout</li>
  <li>it took a job from *job_queue* and then died</li>
  </ul>
  
  <p>For my application, we can probably capture the 2nd case by simply waiting for processing of the job to time out. In production, there will be many workers to supervise, all pulling jobs from a common jobs list and putting results into a single results exchange/queue.</p>