Masstransit: An abstract base class or Interface creates a new Azure Service BusTopic

[joshmouch]

When you add an interface or an abstract base class to a class that is used to publish data with MassTransit, it causes MassTransit to create an undesirable "extra" Service Bus Topic. For example:

This is fine:

public EventData {
 public string Text {get;set;]
}

There will be one Azure Service Bus Topic created called "EventData".

However, if you add an interface:

public EventData : IHasText {
 public string Text {get;set;]
}

Then MassTransit will create an extra Topic called "IHasText".

Is this by design? Is there a way to disable this behavior? I think it causes some quirky behavior when using temporary queues, but I'd have to verify (I'm using a named queue).

[phatboyg]

This is by design, to support polymorphic message consumers - consumers that subscribe to IHasText will get a copy of the message when published.

[brianro]

What about a declarative attribute to ignore that interface or class?

[phatboyg]

Sounds confusing and complicated.

[joshmouch]

Confusing and complicated to implement? It definitely makes looking at the queues and topics more confusing. There's no business-driven reason to ever publish something to an IHasText consumer, so it ends up just being extra clutter in Azure Service Bus.

[phatboyg]

I'd suggest reading the documentation, and look at the examples for RabbitMQ, to understand the why.

http://masstransit-project.com/MassTransit/understand/default-topology.html

If you don't intend to subscribe to IHasText, why do you even have it in your message contract? Message contracts use types to be explicit, having unused interfaces on them just creates confusion. If your interface IHasText isn't adding value to allow message consumers to subscribe to part of a message, then get rid of it.

[brianro]

In our implementation our messaging objects are not a unique set of interface implemented objects. I know this is contrary to your preferred design, but we have a lot of reasons for the implementation. We have created a lot of software surrounding and extending MT.

Our classes are concrete classes that perform transport functions in a couple of different scenarios - similar to a Command pattern. We also use nesting of a "message" object wrapping an "operation" object. The underlying interface and class that is implemented is for other functionality, not receive functionality, for inheritance purposes. The change in this version of MT does change the queues created.

For this reason:

1. Is it possible to add suppress interface syntax of attribute for use during discovery
2. Do the queues for the interfaces require subscribers or will the only be send to if a subscriber is hooked up? i.e. are they like meta-data and won't impact performance if you don't subscribe to them specifically?

[phatboyg]

The shouldn't impact performance if there aren't any subscribers. And I'm not planning to add anything to suppress anything.

[brianro]

Understood. No worries. Thanks for considering it.

From: Chris Patterson [e-mail]
Sent: Tuesday, April 30, 2019 9:18 PM
To: MassTransit/MassTransit [e-mail]
Cc: brianro [e-mail]; Comment [e-mail]
Subject: Re: [MassTransit/MassTransit] An abstract base class or Interface creates a new Azure Service BusTopic (#1430)

The shouldn't impact performance if there aren't any subscribers. And I'm not planning to add anything to suppress anything.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/MassTransit/MassTransit/issues/1430#issuecomment-488169525, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA3BCDBCFEZJI2MNHYHRBNTPTDVULANCNFSM4HI2HCZQ.

[mburumaxwell]

Happy to see this resolved in the latest 7.0.4 release.

[phatboyg]

Oh yeah @joshmouch would
Be happy.

Should have tagged this issue in the commit.