3 ms·
Queue Webhook Events with IronMQ Webhook Support
- kholmes79 14y agoThis is huge. I've been waiting for you guys to release this; thank you for listening!
- newobj 14y agoI 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. What am I missing?
- treeder 14y agoSome 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.