I would love to understand how any message queue can offer "one-time" delivery. At best it seems like a misleadingly under-qualified description, e.g. "one-time-if-the-consumer-successfully-acks-the-message".
Ultimately dequeueing a message, doing work, and acking the message, involve multiple systems in a logical distributed transaction.
Regardless of any guarantees the queue makes, you will need to deal with the fact that the consumer can potentially perform an operation based on the message, and then the ack can fail due to any kind of communication failure between queue and consumer. Or the worker can die (permanently) immediately after performing the work but before performing the ack. Etc. The message will be redelivered and the operation will occur again. As a result, you likely need to ensure that the operation in question is idempotent.
Given that you need to ensure this idempotency regardless of the queue's delivery semantics, I don't see what benefit it is for the queue to make any claims about one-time delivery.
Some queues offer "at-least-once" delivery (such as SQS) meaning even if you do ack/delete the message, you can still get it again. IronMQ will not deliver a message again if it's been acked/deleted.
And yes, work should be idempotent, as is the case with any queue you use.
[+] [-] newobj|13 years ago|reply
Ultimately dequeueing a message, doing work, and acking the message, involve multiple systems in a logical distributed transaction.
Regardless of any guarantees the queue makes, you will need to deal with the fact that the consumer can potentially perform an operation based on the message, and then the ack can fail due to any kind of communication failure between queue and consumer. Or the worker can die (permanently) immediately after performing the work but before performing the ack. Etc. The message will be redelivered and the operation will occur again. As a result, you likely need to ensure that the operation in question is idempotent.
Given that you need to ensure this idempotency regardless of the queue's delivery semantics, I don't see what benefit it is for the queue to make any claims about one-time delivery.
What am I missing?
[+] [-] treeder|13 years ago|reply
And yes, work should be idempotent, as is the case with any queue you use.
[+] [-] kholmes79|13 years ago|reply