Hi Colin, I guess my immediate reading of this is that it could be mighty dangerous in the wrong hands i.e. a very large message store might result if applied too liberally.
When we talked about archiving messages previously we had imagined that timeToLive could come in to play here, though I might well be abusing it's intended purpose. I guess we might also need to be careful around anything which might slow up the 'normal' startup model i.e. when we need to point a new broker instance at an existing BDB store and get the messages in queues for recovery. I'll try to give it some more thought :-) Bfn, Marnie On 1/18/07, Colin Crist <[EMAIL PROTECTED]> wrote:
Hi, A quick question... A common recovery scenario is requesting replay on a queue from a given, known message, either by its ID or by something in the header. Its saves all that mucking about with XA and makes recovery the normal way of system startup rather then some exceptional case. This means when a message has reached all its recipients it should never be marked for removal from the durable message store. As a user, I would also like to control when messages get removed as part of my end of day or even weekly processs, probably based on header property selectors. I don't believe this is supported in AMQP in the wire protocol (nor perhaps should it be) - is it maybe something that could be done via some standardised command messages to a "replay" exchange? Any thoughts on implementation difficulty? Regards, Colin.
