Closed clegendre closed 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 🙂
Thank you for your reactivity and the fix, it works like a charm! 💪
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
Thank you for your help