On 18/01/07, Colin Crist <[EMAIL PROTECTED]> wrote:
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.
Yes - let's just design our systems to handle duplicate and out of order delivery and we can avoid XA in most cases.
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.
Yes, very interesting and useful use case. It would improve throughput for many apps since people would not have to commit the whole message to their database before sending it to the message broker.
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?
In terms of our underlying architecture, this would be relatively easy. We have a delivery table that simply maps from message id to queue, and the message is stored separately. Messages are removed automatically when a ref count hits zero. The removal process is actually handled in the store module so it could do something else easily (e.g if you had a custom store). The admin API could be enhanced to support re-enqueuing of message ids or hard delete of messages. RG
