Idempotency is importantĪ message handler must be idempotent: the outcome of processing the same message repeatedly must be the same as processing the message once. The message handler will still execute the database transaction repeatedly. Specifically, if Apache Kafka invokes a message handler more than once for the same message, it detects and discards any duplicate messages produced by the handler. If you are using a message broker, such as Apache Kafka, that offers a form of exactly once semantics, you might think that your application won’t encounter duplicate messages.īut if you read the fine print, you will discover that the guarantee only applies to Apache Kafka messaging. The message handler might crash, for example.Īlternatively, the broker might crash and lose the acknowledgement.Ī message broker that guarantees at-least once deliver recovers from these kinds of failures by repeatedly delivering the message until it has been successfully processed.Īs a result, a message handler can execute the database transaction multiple times for the same message. It’s possible, however, that the message handler successfully updates the database but somehow fails to acknowledge the message. Second, the message handler updates the database,įinally, it acknowledges the message, which tells the message broker that it has been processed successfully and should not be redelivered. Why can duplicate messages occur?Īt a very high-level, a message handler executes the following pseudo code:Ī message handler loops repeatedly executing the following three steps.įirst, it reads a message from the message broker. Let’s start by looking at why a message broker can deliver a message more than once.
#Masstransit saga queue error how to#
You learn how to prevent those problems by making your message handlers idempotent. In this post, I’ll describe why duplicate messages can occur and the problems they cause. You must use the Idempotent Consumer pattern to ensure that your message handlers correctly handle duplicate messages. It does mean, however, that the message broker can invoke a message handler repeatedly for the same message. Similarly, in the FTGO application, the Order History Service handles Order events by creating or updating the corresponding item in a DynamoDB-based CQRS view.Īn application typically uses a message broker, such as Apache Kafka or RabbitMQ, that implements at-least once delivery.Īt-least once delivery ensures that messages will be delivered.
#Masstransit saga queue error update#
Unless the application is based entirely on streaming, it’s very likely that the message handler will need to update a database.įor example, in the Customers and Orders application, the Customer Service defines the OrderEventConsumer class event handler, which handles an OrderCreated event by attempting to reserve credit for the order. Let’s imagine that you developing a message handler for an enterprise application. Handling duplicate messages using the Idempotent consumer pattern
0 kommentar(er)
