normally, a consumer does GET message from q1 then DELETE message from q1
instead of deleting a message, I would like to move it to another queue, without requiring the consumer to GET/POST/DELETE. instead i would like to GET a message, then POST its unique ID to a second queue, to have it moved from the source queue to a second queue. it is important that the messageID and the other metadata not change so that the consumer can put the the ironMQ message id into a database and track it down later.
two use cases:
i'm processing a message and there's something wrong with it, i would like to put it on another queue so that it can be handled out of band by an exception processing system (which may involve human intervention)
I would like to keep all messages that have been processed so that I can replay them against my app or track down bugs
i think this would be especially important for PUSH queues, too, so that the messages don't just disappear, but can be stored for some period of time and then examined or replayed.
normally, a consumer does GET message from q1 then DELETE message from q1
instead of deleting a message, I would like to move it to another queue, without requiring the consumer to GET/POST/DELETE. instead i would like to GET a message, then POST its unique ID to a second queue, to have it moved from the source queue to a second queue. it is important that the messageID and the other metadata not change so that the consumer can put the the ironMQ message id into a database and track it down later.
two use cases: