4 ms·
> If you retry the SendMessage action within the 5-minute deduplication interval, Amazon SQS doesn't introduce any duplicates into the queue. But what if you t
by dagenix 8y ago
> If you retry the SendMessage action within the 5-minute deduplication interval, Amazon SQS doesn't introduce any duplicates into the queue.
But what if you try to send and at just about the same time the network fails for 6 minutes? The producer then has the option to try to send again, which may produce a duplicate, or, to assume the first send worked, which may mean the message is lost.
In a system that supported true "exactly once" guarantees, the producer wouldn't have to pick between a duplicate message or a lost message, regardless of the length of network outage.
- scarface74 8y agoIf you try to send and the request wasn’t successful, the server would get a connection close and the client would not get a 200 OK. The server would know that the message wasn’t complete.
- orf 8y agoI think that's the crux of your misunderstanding here. There are networking issues where one side thinks a request has been sent or received successfully while the other side does not. In this specific case, if a networking issue prevents the final ACK from being received by the server then the client assumes the connection is closed and the message has been delivered, while the broker will wait for the connection to time out, which I assume is a failure condition. There are other cases where the client can receive a complete message but the server is unsure that it has, and will time out the connection while the client continues processing, assuming everything is fine. You cannot build something on top of a networking stack that does not guarantee exactly-once semantics at any level (TCP, IP, HTTP, physical) and expect to get exactly once. You can mitigate it, sure, so maybe Amazon is super-dooper sure that these networking conditions won't ever happen.