rebus-org / Rebus.AzureQueues

:bus: Azure Storage Queues transport implementation for Rebus
https://mookid.dk/category/rebus
Other
7 stars 5 forks source link

Deferring message using Azure Queues as a one way client #22

Closed clegendre closed 10 months ago

clegendre commented 10 months ago

Hi, I am recently switching from Rebus.SqlServer to Rebus.AzureQueues in order to support our growing messaging throughput. I used to defer messages with the SqlServer transport, but with the AzureQueues transport, I get the following error: Cannot use ourselves as timeout manager because we're a one-way client

I've checked the code, and don't understand the reason behind this message, since AzureQueues transport has a native support for defer. My configuration is simple, I'm using a one way client for sending messages, and this is this one way client that is injected through the whole application. Rebus handlers are using this one way client to defer message in case of errors (in the IFailed).

The simple test to reproduce the issue

                var theBus = Configure
                   .With(new BuiltinHandlerActivator())
                   .Transport(t => t.UseAzureStorageQueuesAsOneWayClient("UseDevelopmentStorage=True" ));

                var azureLocalBus = theBus.Start();

                await sp.Awaiting( x => azureLocalBus.Advanced.Routing.Defer("some-queue", TimeSpan.FromMinutes(10), new object() ))
                    .Should().NotThrowAsync<InvalidOperationException>();

Thank you for your help

mookid8000 commented 10 months ago

It turned out that Rebus.AzureQueues did not make use of Azure Storage Queues' ability to do native defer in the best possible way.

This was fixed in Rebus.AzureQueues 3.1.0 (for Rebus 6 and 7) and 4.0.0-alpha03 (for Rebus 8 pre) which are both available on NuGet.org now

THanks for reporting the error 🙂

clegendre commented 10 months ago

Thank you for your reactivity and the fix, it works like a charm! 💪