In this article, we are going to learn how to leverage Azure’s Service Bus with Brokered messaging to distribute data between systems. Microsoft Azure’s Service Bus is a cloud service that helps facilitate the ability to share data between decoupled systems. As information continues to be the nucleus of our applications, the need to share and the way in which that information must be dispersed will continue to pose challenges. A distributed system is not a new concept but it is a hot topic that continues to grow in popularity with the ever growing need to share data. It's also sort of the fun.The ability to share data between decoupled systems is not a problem that is easily tackled. This failure modeling is meat of the challenge to building reliable systems. If when you say transient error you mean something that lasts and hour or more, you might need to Monitor for errors and pause entire parts of the system (disable all consumers of a queue) until you've restored whatever is broken. You could out exponential back offs between your retries (the new client libraries should extend your lock automatically here), or delays before you teardown a consumer. This would enable the session to be reallocated to another consumer and the redelivery would do to them, hopefully they would have the error.īasically, you need to retry and/or wait in some way till the transient condition passes. So what you could also do is tear down the whole consumer when a message processing error occurs. If not it will be dead lettered, and that's not ideal. The hope is that the transient failure resolves before it reaches the max delivery count. This will increase the delivery count each time. This puts it back on the queue and it will be redelivered. The next option is to abandon the message purposely. Very short lived exception circumstances might recover in that time. They catch your exception and then call you again with the same message. This is what frameworks like Azure functions, masstransit, and nservicebus do.
If it's a transient failure then you have two options, one would be to catch the exception yourself and retry the processing. My question is given knowledge of this problem, what should the consumer do?
See for confirmation of how the bus behaves. What should the consumer do here to safely respond to the issue? If they abandon the AddCustomer, then are they going to spin round a loop of AddCustomer->fail->abondon->AddCustomer until the max delivery count message is reached and the message then dead-letters. If they dead-letter the AddCustomer message, they can't go on to process the RaiseInvoice message since that will fail as the Customer 5678 doesn't exist in the accounting system. If the consumer of the messages has the session lock on AccountID=1234, takes a PeekLock on the queue at T2 for the AddCustomer message and then suffers a transient failure of the accounting system, they are not able to add Customer 5678. T3 - RaiseInvoice for Customer 5678 on Account 1234.The messages all have the session ID as the AccountID owning the entities so that receipt from the bus is in FIFO order in the scope of each AccountID. Please would you suggest how to handle consumer errors in an Azure Service Bus subscription set up to ensure FIFO processing using a session IDs? (See )Īs an example imagine a customer management system posting messages that are consumed by an accounting system.
0 kommentar(er)
