0

I am implementing standard request/response scenario with MT and RabbitMQ. Client is Asp.net core API and consumer is a windows service.

As part of testing the exception cases if I stop the consumer and submit a request from API using request client, since there is no consumer processing, API got request timeout exception which is cool. But the message is sitting in the consumer queue and when I start the consumer, it picks the message and process the stuff( sending the message to external endpoint) and moved to a _skipped queue as there is no request client listening for this message.

Do you think it is correct behavior? First place when the api got request timeout exception, he will retry anyway so what’s the point of processing first message still?

How can I ignore those message where request clients were already finished processing with any error?

Thanks

Janardhan Bikka
  • 92
  • 8

2 Answers2

0

What you are describing is very common, and I'd recommend reading up on idempotence and other distributed system failure scenarios.

Sending commands (the request, in this case) and conveying outcomes via a timeout in a message-based system can be very misleading. For instance, if you look at the ForkJoint, in the event of a request timeout, the response is actually a 202/Accepted instead of communicating an error.

The message is in the queue, it will be processed, so there is no reason to fail the controller and report an error back to the caller. So an intermediate response is used instead.

The sample is part of MassTransit Season 3 where I discuss a new idiom to deal with eventual completion/failure of commands in distributed systems. There might be some useful examples in there to help you understand the failure scenarios.

Chris Patterson
  • 28,659
  • 3
  • 47
  • 59
0

As doc sayed, to discard skipped messages so they are not moved to the _skipped queue:

cfg.ReceiveEndpoint("input-queue", ec =>
{
    ec.DiscardSkippedMessages();
});
afruzan
  • 1,454
  • 19
  • 20