4 ms·

Well, not quite. What SQS actually offers is: exactly once delivery, except when the message is delivered multiple times. Quoting from the SQS docs [1]: > The

Well, not quite. What SQS actually offers is: exactly once delivery, except when the message is delivered multiple times. Quoting from the SQS docs [1]: > The visibility timeout begins when Amazon SQS returns a message. During this time, the consumer processes and deletes the message. However, if the consumer fails before deleting the message and your system doesn't call the DeleteMessage action for that message before the visibility timeout expires, the message becomes visible to other consumers and the message is received again. If a message must be received only once, your consumer should delete it within the duration of the visibility timeout. If a consumer receives a message and then loses its network connection to SQS, the visibility timeout will expire before it can delete the message and it will be delivered a second time to another consumer. I would very much suggest reading through the linked article by GP and maybe more about the Byzantine Generals Problem which establishes why exactly once delivery isn't just hard, but impossible. And Amazon's marketing department can't change that. [1] https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-visibility-timeout.html#configuring-visibility-timeout https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQS...

deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
scarface74 8y ago
Or you could post the quote from the link I posted. You can now use Amazon Simple Queue Service (SQS) for applications that require messages to be processed in a strict sequence and exactly once using First-in, First-out (FIFO) queues. FIFO queues are designed to ensure that the order in which messages are sent and received is strictly preserved and that each message is processed exactly once
- dagenix 8y ago
  What exactly is it about: > However, if the consumer fails before deleting the message and your system doesn't call the DeleteMessage action for that message before the visibility timeout expires, the message becomes visible to other consumers and the message is received again. that you fail to understand. The phrase "received again" means that the message is delivered more than once. More than once is more than exactly once. The quote you are referencing is marketing nonsense.
  - scarface74 8y ago
    If you want the message to be only received once regardless of whether it was successful processed, you set the MaxReceive count to 1 and set up a dead letter queue as part of the redrive policy and you use fifo queues instead of the standard queue. It isn’t “marketing nonsense”. It’s more just quoting from one site on the Internet, instead of understanding the system as a whole.
    - orf 8y ago
      That would make it at most once delivery.
      - scarface74 8y ago
        The fact that a process did a GetMessage means it was delivered at least once.
        orf 8y ago
        It does? How? Can you think of any conditions that might make that not true? Like you said several times, knowing what’s going on takes more than just reading several AWS documentation pages. And to boot, that stretches the definition of delivery. You’d hardly consider a letter delivered if the postman left it outside the postbox and it blew away.
        scarface74 8y ago
        There are really only a few cases when using fifo queues This will happen no matter what: Message enqueued -> getMessage called -> message visibility state set to invisible -> Various conditions: 1. message processed successfully -> message deleted. message delivered exactly once 2. Message failed to process successfully -> process caught error -> invisibility timeout manually set to 0 by process -> message ends up in DLQ exactly once delivery 3. Message processed successfully -> client failed to delete message —> message times out automatically -> message delivered to DLQ exactly once delivery And to boot, that stretches the definition of delivery. You’d hardly consider a letter delivered if the postman left it outside the postbox and it blew away. The message in the failure case didn’t “blow away”. AWS guaranteed exactly once delivery and it put the messages that failed in a dead letter queue. It’s up to the business to decide remediation steps in failure cases. You can even set up an alert when the DLQ is not empty.

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

scarface74 8y ago

Or you could post the quote from the link I posted. You can now use Amazon Simple Queue Service (SQS) for applications that require messages to be processed in a strict sequence and exactly once using First-in, First-out (FIFO) queues. FIFO queues are designed to ensure that the order in which messages are sent and received is strictly preserved and that each message is processed exactly once

dagenix 8y ago
What exactly is it about: > However, if the consumer fails before deleting the message and your system doesn't call the DeleteMessage action for that message before the visibility timeout expires, the message becomes visible to other consumers and the message is received again. that you fail to understand. The phrase "received again" means that the message is delivered more than once. More than once is more than exactly once. The quote you are referencing is marketing nonsense.
- scarface74 8y ago
  If you want the message to be only received once regardless of whether it was successful processed, you set the MaxReceive count to 1 and set up a dead letter queue as part of the redrive policy and you use fifo queues instead of the standard queue. It isn’t “marketing nonsense”. It’s more just quoting from one site on the Internet, instead of understanding the system as a whole.
  - orf 8y ago
    That would make it at most once delivery.
    - scarface74 8y ago
      The fact that a process did a GetMessage means it was delivered at least once.
      - orf 8y ago
        It does? How? Can you think of any conditions that might make that not true? Like you said several times, knowing what’s going on takes more than just reading several AWS documentation pages. And to boot, that stretches the definition of delivery. You’d hardly consider a letter delivered if the postman left it outside the postbox and it blew away.
        scarface74 8y ago
        There are really only a few cases when using fifo queues This will happen no matter what: Message enqueued -> getMessage called -> message visibility state set to invisible -> Various conditions: 1. message processed successfully -> message deleted. message delivered exactly once 2. Message failed to process successfully -> process caught error -> invisibility timeout manually set to 0 by process -> message ends up in DLQ exactly once delivery 3. Message processed successfully -> client failed to delete message —> message times out automatically -> message delivered to DLQ exactly once delivery And to boot, that stretches the definition of delivery. You’d hardly consider a letter delivered if the postman left it outside the postbox and it blew away. The message in the failure case didn’t “blow away”. AWS guaranteed exactly once delivery and it put the messages that failed in a dead letter queue. It’s up to the business to decide remediation steps in failure cases. You can even set up an alert when the DLQ is not empty.