However, this article approaches the problem from a more generic perspective. You can also use this policy to avoid loops, rather than managing your own counters. SQS also offers Redrive Policy which employs a “Maximum Receives” attribute representing the maximum number of receives before the message is sent to a dead letter queue. Luckily, SQS maintains just such a managed attribute at the message level (ApproximateReceiveCount) and we will use this in our sample retry setup. If we are dealing with a consumer fleet, we need to move this Map to a central repository such as Redis or an RDBMS. delivery_count in the consumer application. For these kinds of brokers, we can maintain a Map of message_id vs. JMS 2.0 defines a managed header attribute for broker re-deliveries, but this is not available on all other non-JMS broker implementations. This will allow for the replaying of the failed messages in the future. If the consumer realizes that the message has reached its maximum retries, the consumer will move that message to another queue (dead letter queue). On every consumption, this counter is increased by 1. The message header or an external system should keep track of the re-delivery count of the same message. To tackle this problem, we need to introduce a “maximum retries” feature. There is a possibility of endless loops in here, which we should also avoid. The same cycle starts again which will lead to a retry of the same message.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |