rebus-org / Rebus.RabbitMq

:bus: RabbitMQ transport for Rebus
https://mookid.dk/category/rebus
Other
65 stars 45 forks source link

Breaking change and wrong versioning on Publisher Confirms #96

Closed arielmoraes closed 2 years ago

arielmoraes commented 2 years ago

We updated the lib from 7.3.4 to 7.3.5 and the Publisher Confirms now has a Timeout, before that it was using the overload without parameters thus using an infinite timeout.

We received an alert that our queues were growing very fast because we have a flow that publishes several messages inside a handler, the problem happens because the timer starts on the very first message, so if the publish process takes more than 1 minute (the default timeout used on the 7.3.5 version) the handled message is unacked and processed again and the retry policy is not being applied on that stage. That caused our rabbit to almost hang up because the handled message never stopped processing.

For us, that was a breaking change as reverting to the 7.3.4 version made it work again. I think that parameter should be optional and configured on the transport initialization.

mookid8000 commented 2 years ago

I've made the timeout configurable in Rebus.RabbitMq 7.4.1, which is available on NuGet.org now 🙂

Just go

services.AddRebus(
    configure => configure
        .Transport(t => t.UseRabbitMq(...)
            .SetPublisherConfirms(enabled: true, timeout: TimeSpan.FromMinutes(2)))
);

or

services.AddRebus(
    configure => configure
        .Transport(t => t.UseRabbitMq(...)
            .SetPublisherConfirms(enabled: true, timeout: TimeSpan.Zero))
);

to have an infinite timeout. Thanks for making me aware of this problem.

arielmoraes commented 2 years ago

Thank you for the fast response, just one question, why don't the handled messages on that step go to the error queue?