Go into the RabbitMQ management interface (see this post for instructions – should be at and click on the Queues tab. Next question… where’s the TicketOpened message now? Since our exception isn’t really transient, then it’s going to try 5 times without success. There’s no delay between retries (we’ll look at that later). What’s going on here? What MassTransit does, by default, is retry any message that causes an exception to be thrown in its consumer exactly 4 more times. Take a look at the log file ( C:\Logs\) and you’ll see these entries: Now we can run the app, open a ticket, and type “poison” into the message field to get our consumer to throw the exception: We just check to see if the text of the message contains the word “poison” and, if it does, throw an exception. "Your Message:\n" ĮmailHelper.Send(, "Ticket Opened", messageBody) "We will respond to your inquiry ASAP.\n\n" Var messageBody = "Ticket ID " " has been opened for you! " Send email confirmation to the customer. Throw (new Exception("Something bad has happened!")) For this example, we'll just write it to the trace log. Here is where you would persist the ticket to a data store of some kind. Public void Consume(IConsumeContext envelope) Here’s the new Consume method in our class: using Ĭlass TicketOpenedConsumer : Consumes.Context The final code is in the same repository, but in the error-handling branch. Start by cloning the repository (master branch) or by building the application in my previous blog post. To see what MassTransit does, let’s inject a way to get the consumer to throw an exception. Let’s start by looking at what the default MassTransit behavior is when an exception occurs in your consumer. As you know, there’s a number of things that could go wrong. If we were persisting to a data store, that could be down, or maybe there was a SQL deadlock. So what will happen to our TicketOpened messages if there’s an error in the TicketOpenedConsumer? In our example, we’re only sending an email, but the email server could be down. Let’s look at how we can leverage the message queuing infrastructure to handle what may be transient errors as well as perhaps more permanent failures. We all know, however, things can and will go wrong. (I recommend you review the blog post if you aren’t familiar with it as we are going to build on that application here.)īut what happens when something goes wrong? Blog posts usually assume the happy path when showing code examples in order to keep them easily digestible. Then, we built a Windows Service, using the TopShelf library, that subscribed to TicketOpened messages and handled creating the ticket and emailing the customer a confirmation email. The website created a TicketOpened message and published it to the MassTransit service bus. Previously, we built a simple Customer Portal application where a user could use an ASP.NET MVC app to open a new customer service ticket.
0 Comments
Leave a Reply. |