[rabbitmq-discuss] Implementing a "processing" queue with message expiry

[Derek Chen-Becker]

On 01/12/2011 12:37 AM, Steven Taylor wrote:
> 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)
>  
> "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. 

I agree. In our case we have a workflow that actually manages the state
of the overall process. A given job may get executed more than once due
to some pathological condition, but the workflow acts as a master
controller to make sure that once a job has been marked as done, further
notifications of job completion just get ignored.

Derek