How can you handle an error such as no handler found?

[frostebite]

Consider the scenario where you want to use Request Reply. But some subscribers may not have a handler for all types of event. And the timeout is set to be quite long. You don't want to always wait for timeout when the system should immediately pass up on an event type it doesn't handle.

[mookid8000]

Hmmm..... I can't help to wonder why you would send a request to an endpoint that might not be able to handle it....?

In my world, it would be extremely seldom and a clear sign that something is wrong if and endpoint is not able to handle a received message.

Maybe you could tell me some more about which kind of problem you are trying to solve?

[frostebite]

admittedly the exact mechanism or structure of subscribing, routing and the queues still isn't super clear to me. If it helps I'm familiar with azure service bus's topics and subs.

That said, this is quite a specific use. We'd like to use the full azure service bus setup but without netcore support we can't.

However we are implementing this as a sort of in memory message bus for hitting actual events.

We need the thread that executes the initial publish to await the completion before continuing so we're using the rebus.async packages and just sending a bool back as a response. Otherwise if we do not wait the azure service bus listener will just fire all the messages in quick succession.

Input welcome :)

[mookid8000]

(...) but without netcore support we can't.

However we are implementing this as a sort of in memory message bus for hitting actual events.

Does this mean that you are running .NET Core, using the official Azure Service Bus driver to manually receive messages, and then you do an in-mem dispatch to handlers using Rebus' in-mem bus?

We need the thread that executes the initial publish to await the completion before continuing (...)

I recommend you strive after designing your system such that publishers only publish events because they're nice, not because it means anything to them. It should be each subscriber's responsibility only to subscribe and handle the received events properly.

But of course if this is because you're using Rebus to do in-mem dispatch if the received messages, then I suddenly understand why you feel this need.

This sounds kind of hacky (in a less optimal way) to me 😟 😁

Have you considered changing to using Azure Storage Queues? Rebus has .NET Core support for them, and combined with the table storage-based subscription storage, you can use Rebus with a simple storage account as if it was a topics-based service bus....

[frostebite]

The answer to the first section is: yes.

When I say the mechanism for subscribing isn’t clear to me I mean having a single input queue with the ability to call subscribe on different types? How does this model map to Azure service bus.

Right now the events to publish in this way correctly without awareness of subscribers.

Regard storage queues. That probably won’t work, we have other systems wanting to receive certain events in any number of other colourful languages or frameworks. We’re happy to work on the Azure service bus fix for rebus and netcore I have a team with some bandwidth see my response in the service bus issue about this.

[mookid8000]

When I say the mechanism for subscribing isn’t clear to me I mean having a single input queue with the ability to call subscribe on different types? How does this model map to Azure service bus.

Simply by creating a topic for each topic publishes/subscribed to from Rebus.

When you subscribe to a topic, Rebus then creates a subscription beneath that topic, configuring it to forward received messages to the subscriber's input queue.

Regard storage queues. That probably won’t work, we have other systems wanting to receive certain events in any number of other colourful languages or frameworks.

Azure Storage Queues' native API is based on HTTP. It's accessible from any platform that can make an HTTP request 😄

[frostebite]

When you subscribe to a topic, Rebus then creates a subscription beneath that topic, configuring it to forward received messages to the subscriber's input queue.

for async does this mean you must or must not subscribe to the reply type?

Simply by creating a topic for each topic publishes/subscribed to from Rebus.

not sure I follow there ha.

Azure Storage Queues' native API is based on HTTP. It's accessible from any platform that can make an HTTP request 😄

But polling required and a less standardized format and feature for other languages that can't use rebus :/ we're much keener on service bus <3

[mookid8000]

for async does this mean you must or must not subscribe to the reply type?

Yes! "Subscribing" means you receive something when someone is "Publishing".

Request/reply is in no way connected to pub/sub.

not sure I follow there ha.

Yeah well, ok – if you familiarize yourself with how Azure Service Bus works, then I think it might make more sense 😉

But polling required and a less standardized format and feature for other languages that can't use rebus :/ we're much keener on service bus <3

Polling is required, yes. Rebus has a configurable (and completely customizable) backoff strategy, so you can tweak this aspect to avoid doing too much unnecessary work.

But since it's HTTP, it's accessible from basically anywhere. I can think of no other protocol with such wide support as HTTP.