Queue Exceptions and .Ack from within the handler (RabbitMq)

1

Hi,
this is how I register a handler and start the server:

container.Register<IMessageService>(c => new RabbitMqServer("rabbitmq:5672") { RetryCount = 1 });
var mqServer = container.Resolve<IMessageService>();
var phoneQueue = container.Resolve<PhoneQueueHandler>();
mqServer.RegisterHandler<PhoneQueueModel>((x) => phoneQueue.Handle(x));
 mqServer.Start();

this is how I publish

using (var mqClient = MessageService.CreateMessageQueueClient())  {
      mqClient.Publish(new PhoneQueueModel { Context = request });
}

  1. Since the handler is an injected service, how do I report the .Ack() when the handling is done (from within the handler)?

  2. When I throw an exception from the handler, I don’t see a retry as well.

BTW, Even though .Ack() was not invoked. there is no retry.

Thanks

2

Ack’s are automatically sent by the Message Handler for successful message handlers that don’t throw Exceptions.

See the linked tests in the docs under the list of MQ Server options for integration tests which verifies the behavior of the Message Workflow documented in the docs.

3

Ok. .Ack is not mandatory.
But, when I throw an exception, I dont get a retry.
Thanks for the fast reply.

4

The linked integration tests in the docs verify the behavior of the MQ Handlers, start with those and compare them with your code to workout the discrepancy.

5

Wait I’ve discovered an issue with Rabbit MQ, stay tuned for an update…

1 Like
6

Ok.
FYI, Im using 5.8.1.

7

ok nvm, the issue I thought I had a failing local test but it was because I had dirty messages in the existing MQ’s so I’m now purging the messages before the tests are run:

The other issue is due to an AppHost being required to generate the Error DTOs, if you don’t have one (i.e. trying to run this outside of a ServiceStack App) you can create an empty AppHost with:

using var appHost = new BasicAppHost().Init();

Other than that all tests should pass:

image
image1034×523 38 KB

8

ok I’ve changed it to no longer require an AppHost, pushing change through CI now, should be on MyGet within 45 mins.

9

Thanks.
My exception problem was because my handler is an async function.
So now the exception is catched by SS and the retry is invoked.
Can a handler be awited async function?

Also, in this function https://github.com/ServiceStack/ServiceStack/blob/8ef9dbf3c7d2f4220b55d8c2913e9f9600094dfb/tests/ServiceStack.Server.Tests/Messaging/MqServerIntroTests.cs#L224 you are calling .Ack,
if the framework handle that, why does the tests invoking it?

Thanks

10

No it doesn’t expect it to return a task so it can’t asynchronously await it.

This Ack? It’s retrieving the message directly from the .dlq MQ, (i.e. outside of processing the MQ message) when retrieving messages manually your App needs to make the decision when it has taken responsibility of it with an explicit Ack.

11

Perfect. clear. thakns