[FEATURE REQ] Service bus ReceiveDeferredMessageAsync from a processor

Library or service name. Azure.Messaging.ServiceBus

Is your feature request related to a problem? Please describe. Currently, receiving of a deferred message can only be done through a receiver.

Since ServiceBusProcessor encapsulate the receiver, the only way to receive a deferred message is by creating a duplicate receiver instance.

I understand that the processor is not a receiver and thus might want to encapsulate the receiver but it might be that defer operation logic does exist within the processor and perhaps it is possible only to expose a method that will allow receiving deferred message through the internal receiver. The processor args already allow deferring, so it seems logical (to me) that it will also allow receiving these deferred message later.

Thanks!

[shlomiassaf]

Well, we’ve implemented a small library on top of Azure.Messaging.ServiceBus.

Basically we’ve added plugins and pipelines, wrapped with container support for DI. We’ve made each bus message closer to an incoming HTTP request in a server.

We have a backoff retry mechanism which, based on certain exceptions, emits the message back to service bus with a schedule time and a label to follow on the count.

We’ve used to do it via message cloning, which OK but not optimal (as we see it)

• Its not transactional as 2 calls are required (complete current, submit new).
• It’s a bit verbose (cloning mostly)
• It requires a special, short-circuiting filter rule, on subscriptions so we only retry on the relevant subscription within the topic. And ofcourse submitting the clone with a header-flag for that filter.

The filtering issue has the biggest impact since rule filters are “OR” but we must short-circuit on retry submit so we need to join filters into one expression.
Of course, filters comes with a performance hit…

All of the above is solvable.

• We can use a transaction scope
• We can schedule and submit to a designated queue with a “response” address which will have a handler that will forward it to…

Lot’s of solution… but all has tradeoff.

The best one, as we see it, is using the defer mechanism. Since our Retry plugin is the one that intercept the initial message as well as submit retry messages we can use defer to put the message aside and emit an empty scheduled message which we can identify, and use it (on arrival) to fetch the deferred message (Marker message will hold the sequence number).

This is not perfect but it’s the best solution we see.
Instead of filters we can now mark on the scheduled message the original subscription so all other subscriptions will ignore their messages (via the plugin), their light so it’s not an issue and we don’t filter. With filtering we filter for every message while here its only on retry.

It will also work with sessions because the same handler will get the marker message… keeping all session rules in place.

I’m sure there are more use cases…

[JoshLove-msft]

Hi @LeszekKalibrate, I’ve added this to our April milestone which means we will try to have it release in April.