[ESDB-169-3]: Migration of internal message dispatcher/scheduler to async#4408
[ESDB-169-3]: Migration of internal message dispatcher/scheduler to async#4408
Conversation
The ReaderSubscriptionDispatcher expects its subscribers to be of type IHandle instead of IHandleAsync.
…ness of the root cause)
…n rather than not calling it
Buses and MessagesThe ESDB server architecture is a message processing pipeline, with stages passing messages to each other via queues. There are three main interfaces for message processing:
They are all similar in that they have a method that takes a message as a parameter. The primary difference is their intent.
Interface non-guaranteesNone of the interfaces (
Such guarantees can be obtained, but they depend on the concrete implementations, and often depend on the way in which the concrete implementations are arranged in the pipeline. Best practices
Introducing Async HandlingEverything above was true before async handling was introduced and remains true after it. We are not changing the message processing principles, or the intentions behind the interfaces. We want to be able to handle messages asynchronously (e.g. so that reads can reach out to async APIs such as S3). So naturally we introduce On the calling side, places that used to call On the implementation side, end handlers implementing When called non-concurrently (which is typical), the There is now no implementation of |
This reverts commit b813b75.
Changed:
InMemoryBusbecomes asynchronous dispatcher. Async handlers now can useIAsyncHandle<T>interface to enable async execution.Removed:
IBusinterface is removed with no replacement to clearly distinguish roles of message dispatcher and message scheduler. Removed unused schedulers and related tests.