rebus-org / Rebus.AzureServiceBus

:bus: Azure Service Bus transport for Rebus
https://mookid.dk/category/rebus
Other
33 stars 20 forks source link

Using path in connection string no longer works #17

Closed vegar closed 5 years ago

vegar commented 5 years ago

We have some services using v3 of rebus. Now we have a new .net core based service using v6.

When sharing a single service us between multiple developers in test environment, we have included the machine name in the connection string for namespacing. e.g. Endpoint=sb://sharedbus.servicebus.windows.net/mymachine;SharedAccessKeyName=....

In the .net core world, this doesn't work. The path-part of the endpoint is ignores.

I'm not sure if it is because of the new Rebus.AzureServiceBus-implementation, or if it is the new azure-service-bus-dotnet, and I have to admit that I don't know rebus nor service bus good enough to know where to start digging...

My rebus setup is simple:

            var bus = Configure
                .With(_activator)
                .Logging(x => x.Serilog())
                .Transport(t => t.UseAzureServiceBus("Endpoint=sb://...servicebus.windows.net/mymachine;...., "MyInput"))
                .Options(o =>
                {
                    o.SimpleRetryStrategy(_rebusOptions.ErrorQueue);
                })
                .Start();

            await bus.Subscribe<MyEventMessage>();

I would expect a mymachine/myinput-queue, and a mymachine/myeventmessage-topic with one subscription. Instead I get myinput-queue and myeventmessage-topic.

Any idea what changed? Is there a different way of achieving my desired result?

vegar commented 5 years ago

Is there a different way of achieving my desired result?

Decorating the ISubscriptionStorage seems like a good fit. The queue names are easy to prefix anyway.

mookid8000 commented 5 years ago

I've investigated this now – Rebus' Azure Service Bus transport is passing the connection string directly to ManagementClient, which it then uses to create its queues.

It seems the management client might deviate slightly from how the old driver worked.

If you want queue names with slashes in them, you can simply put it in the queue name, so I suggest you simply prefix your queue names.

vegar commented 5 years ago

Yes, I prefix my queue names manually to resolve this. My problem was that the topic names was not prefixed, which caused trouble. But I solved this by decorating the ISubscriptionStorage.

Thanks for making the effort to check if the deviation was in rebus or the new service bus library. I'll see if I'll report it there as well, or just live happily with my workaround :-)

mookid8000 commented 5 years ago

Ah, now I understand why you suddenly brought the subscription storage into the talk 😁 pretty clever solution!

vegar commented 5 years ago

I won’t take credit for neither the existence of a ISubscriptionStorage nor the convenient Decorate method that I found ;-)