[rabbitmq-discuss] Queue and filtering questions

[Matthias Radestock]

Andrew,

On 17/11/11 02:49, Andrew Esler wrote:
> The reason I want to do filtering server side is then I have easy
> access to the info I need for filtering. If filtering is done client
> side, then all clients have to know about each other and tasks they
> are working on in order to be able to find the information they need
> to make filtering decisions.

It is not obvious from your earlier problem statement why there would be 
a need for clients to know about each other.

You said "I would like to be able to filter messages from the output 
queue that were sent before the worker failed so they are not delivered 
twice.". So there must be some mechanism in place that detects worker 
failure. Could that not trigger an event that is broadcast to all the 
consumers of the output queue, so that they can subsequently filter out 
the results of the failed worker?

I wonder though whether this complexity is really necessary. The failure 
detection can never prevent duplicates completely - after all, some of 
the results of the dying worker may already have been processed. So 
given that the system needs to cope with that anyway, is really worth 
putting a secondary mechanism in place? That would only make sense if 
the worker failure frequency is high and the cost of ordinary duplicate 
handling is high.

Regards,

Matthias.