Back to Blog
Masstransit fault responseaddress5/4/2023 If you type “Retry.” in the editor then IntelliSense will show you several options. The Retry class exposes a wide range of retry policies. If you now run the same test then you’ll see that the same command message is re-sent 5 times in quick succession before it ends up in the _error queue. This assigns the retry policy to the bus, so it’s a more general policy than on the consumer level. IBusControl rabbitBusControl = (rabbit => The same UseRetry extension method is available within the Action supplied to the CreateUsingRabbitMq function: The Immediate method accepts an integer and sets up a policy to resend a message that many times with no delay in between. The UseRetry extension method accepts an IRetryPolicy interface where the Retry class offers a number of shortcuts to build an object that implements the interface. Rabbit.ReceiveEndpoint(rabbitMqHost, "", conf => The retry policy for the receiver is declared in the ReceiveEndpoint method as follows: Probably the most basic retry policy is to tell MassTransit to resend a message a number of times before giving up, i.e. We can easily declare a retry policy for a specific consumer or for the service bus as a whole. We can declare various retry policies in MassTransit but by default there is no retry policy at all. We saw above that the publisher published a message and the message ended up in the error queue after a single try. You can even set up consumers for these queues if you to process them further, e.g. Therefore it’s important to check the _error and _skipped queues periodically. Skipped queues store messages that cannot be routed to the queue for some reason. Here’s our message:Īs extra information we can mentioned that there are also “_skipped” queues, like “_skipped” in our case. This queue is named after the queue that the receiver is listening to with “_error” attached to it. So what happened to the message? By default it ends up in another queue. The exception is thrown in the consumer and you’ll see the stacktrace printed in the consumer’s command window: The publisher will send the usual IRegisterCustomer object. Start the receiver application and then also start MassTransit.Publisher. Visual Studio will warn you that the rest of the implementation is unreachable, but we don’t care for now. Throw new ArgumentException("We pretend that an exception was thrown.") Insert the following line just before newCustomer is declared: IRegisterCustomer newCustomer = context.Message Ĭonsole.WriteLine("A new customer has signed up, it's time to register it in the command receiver. Public Task Consume(ConsumeContext context) What happens then? Let’s see.Ĭurrently we have a consumer called RegisterCustomerConsumer in our MassTransit.Receiver console demo application. It happens that an exception is thrown in the consumer class so that it cannot acknowledge the message. In this post we’ll take a look at various failure handling options in MassTransit. This is the contrary of control-freak objects that construct all their dependencies hidden in their implementations. Good software engineering dictates that a class should indicate what dependencies it needs through e.g. Consumer classes will often have at least some sort of dependency such as a repository interface or another abstraction to propagate the changes made. Type genericHandler = typeof(GenericHandler).In the previous post we explored how to inject a dependency into the registered consumer class in MassTransit. Publish a request public IGenericResponse PublishRequest(TMessage message, Type potentialResponseTypes)įoreach (Type responseType in potentialResponseTypes) I wanted to implement this in a generic way so I could wire up other services with similar requirements in the same way. I needed to publish a message across the ESB (MassTransit) that will return a different type of object depending on how the message is processed.
0 Comments
Read More
Leave a Reply. |