rebus-org / Rebus

:bus: Simple and lean service bus implementation for .NET
https://mookid.dk/category/rebus
Other
2.3k stars 356 forks source link

Upgrade from Rebus 5.4.1 -> 6.2.1 - Azure Service Bus messages not being picked up #881

Closed michaeldtaylor closed 4 years ago

michaeldtaylor commented 4 years ago

I am currently investigating this but have not yet done any extensive digging, but I just in case it was something obvious, this might save me some time.

I was using:

<PackageReference Include="Rebus" Version="5.4.1" />
<PackageReference Include="Rebus.AzureServiceBus" Version="6.0.7" />
<PackageReference Include="Rebus.ServiceProvider" Version="4.0.2" />
<PackageReference Include="Rebus.SqlServer" Version="5.1.0" />

I upgraded to latest as of 27/05/2020:

<PackageReference Include="Rebus" Version="6.2.1" />
<PackageReference Include="Rebus.AzureServiceBus" Version="7.1.3" />
<PackageReference Include="Rebus.ServiceProvider" Version="5.0.6" />
<PackageReference Include="Rebus.SqlServer" Version="6.1.2" />

No user code has changed and this was working fine.

What I see:

  1. I pick up a message from a Storage Queue and _bus.SendLocal(Message). I see the message on the Azure Service Bus queue, but nothing is picking it up. In my ServiceProvider "services" I see the IHandler registered (which in this case is an Idempotent saga). I am using:
services.AutoRegisterHandlersFromAssemblyOf<Program>();

to register handlers, as I always have.

  1. Azure Service Bus has created topics with a different naming convention. Used to be:

addr_portfolio_core_infrastructure_appheartbeat__addr_portfolio_core

Now:

addr.portfolio.core~addr.portfolio.core.infrastructure.appheartbeat

However, the same number of subscriptions are present for each and they are pointing to the same queues, so that should be ok?

I do get this message in Azure Service Bus when I click on the topic:

"ARM does not support resource names containing the '/' character. Service Bus converts these slashes to '~' when interfacing with ARM, but retains the slashes in its backend. Your entities with slashes in their names may appear with tildas instead in certain blades of the Portal, but Service Bus supports and will continue to support these resources with their original format with slashes."

At this stage, is there any obvious reason as to why the Saga handler would not be picking up the message?

Thanks,

Michael

michaeldtaylor commented 4 years ago

Ok, well I just changed to use "FileSystem transport" and I have the same issue. So its nothing to do with Azure Service Bus message topics. The Saga is not picking up the queue message since upgrading.

michaeldtaylor commented 4 years ago

Right, I think I have figured it out. Did 5.4.1 implicitly start/or was started the first time the IBus instance was resolved? I noticed that my resolved IBus instance had workers of 0. If I grabbed the IBusStarter out of ServiceProvider and called Start things started working again.

What is the canonical way to start the bus if using ServiceProvider? I'll look through the source for that in the meantime.

michaeldtaylor commented 4 years ago

Looks like I was basically right. You have an IServiceProvider "UseRebus" extension method which basically does what I was doing above. In a .NET 3.1 console app I am using:

public static IHostBuilder CreateHostBuilder(string[] args)

So I don't have direct access to the IServiceProvider and end up having to do:

var host = CreateHostBuilder(args).Build();

host.Services.UseRebus();

await host.RunAsync();
mookid8000 commented 4 years ago

Looks like you figured it out 🙂 calling

host.Services.UseRebus();

was the missing piece.

I must admit though, that I have heard about several occasions where people have forgotten to call this method, because it's not entirely obvious. Do you have any ideas on a better way to make the coder remember to start the bus?

michaeldtaylor commented 4 years ago

Not sure to be honest. The interesting thing to me is why I didn’t need to do this previously in Rebus v5? Seems like something I should have needed to do, but for whatever reason didn’t. Also, not that it matters but why did the Azure Service Bus topic naming strategy change? Any reason?

mookid8000 commented 4 years ago

The naming strategy was changed, because is was needlessly conservative in which characters it would allow. IIRC it would lowercase all topic/queue names, remove /, etc.