No-delay (push) receives

[jods4]

Rebus is generally working with a polling receive loop: ReceiveAsync is called, if there is no message (call returns null) then there is a short wait time and ReceiveAsync is called again.

I am considering optimizing the transport I use so that there is no wait time. This might be possible because a "push" side-channel exists so that the transport would know instantly when a message is available.

To integrate this in Rebus, what I have in mind is that ReceiveAsync may never return null. The task would remain pending until either the bus shuts down (by means of its cancellation token), or a message was pushed and can be instantly received.

Would this be a reasonable approach? Is there a downside or problem to having ReceiveAsync block for very long periods of time?

[mookid8000]

Some Rebus transports (like the ones for RabbitMQ and Azure Service Bus) use PREFETCH internally, causing there to be 0 waiting time and probably no actual I/O as part of the receive loop, which makes it pretty efficient.

Rebus also natively supports backing off during idle times, so it will by default wait 100 ms between polls during the first 10 seconds of running idle, and then it will poll every 250 ms after that. On most normal machines, it will look as if the CPU .isn't actually doing anything.

There hasn't really been any good reason yet, in my opinion, to change the polling nature of Rebus' receive loop. I may of course be wrong 🙂 but yeah, that's currently how things work.

Since the CancellationToken passed to the Receive method of ITransport won't be signaled until Rebus is supposed to shut down,
I think a viable approach would be to build a simple async semaphore/concurrent queue-based(*) in-mem queue, which could work as as buffer with built-in work signaling via the semaphore.

The push callback in your app could then insert messages into that queue, and your Rebus transport would then just use the normal loop in the normal way to poll for messages.

Would this be a reasonable approach?

TL;DR: yes 😆

---

(*) For example based on @StephenCleary's brilliant AsyncEx library where you can find the nifty AsyncSemaphore: https://github.com/StephenCleary/AsyncEx/blob/master/doc/AsyncSemaphore.md

[jods4]

Thanks for answering!

When you say Rabbit or ASB use prefetch for 0 waiting time... you mean zero waiting time when the next item has already been prefetched before you even call receive? But you still have the loop waiting time (assuming your last check was empty), right?

My situation is consumers that rarely receive messages. So basically when you send one message to them, on average waiting_time / 2 goes by before they notice the new message and start processing.

I'm thinking about reducing this because I have multiple "hops" in a message chain (like Saga basically) and these accumulate and create latency, especially in worst case.

One way to reduce this is to lower the wait time, I see you suggest 100ms or 250ms.
It's true that most systems would not even notice the load of 10 queries/sec.

I have other stuff on plate but I'll come back to this later.
As you say this is reasonable, maybe I'll look into doing a PR for low-frequency polling with query notifications for immediate receive. 🤞