the system I’m developing has multiple clients sending requests to 3 queues with multiple servers servicing one or more of these using a ServiceBusProcessor (not a ServiceBusReceiver) in PeekLock mode, AutoComplete false, prefetch and max concurrent 1.

Each server can take anywhere from ~1 to ~10 seconds to process a request, and can only ever process one at a time (it’s a heavy number crunching thing that runs as many threads as the server can handle, so running >1 would kill performance).

As such, I want each server to receive a message via the OnReceived event handler, process it and not get any other requests until I have completed (or abandoned) the one that is being processed.

I get a message via the event handler, process it and complete it; I am using PeekLock as I thought that would stop the processor getting more messages until it had finished, but that seems not to be the case. There’s no real need to abandon messages or explicitly complete them, am only using PeekLock as I though I needed to do that to force requests to come one-by-one.

This was simple with Rabbit but I’ve recently switched over to using ServiceBus, and while it works OK in general, I find servers that have locked and are processing a message are sometimes getting another message, and another, before I have completed (or abandoned) the one that’s being processed.

If I drop down to just one server to make the problem more obvious, each new message is immediately sent on to the server as it’s queued – but I want the messages to back up in the queue and possibly be auto DLQ’d if the server can’t handle them in time.

I can’t find any definitive statement in the documentation or elsewhere to say that once a server had peek-locked a message, the processor won’t get another message, and can’t find any option/setting to make that happen, quite possibly because it’s not something that a ServiceBusProcesser can do but I wish I could find a definitive statement about it somewhere.

Right now, I’m doing what seems very much like a hack; I am calling StopProcessing() on the queue on receipt of a message and StartProcessing() when the server is ready to process another, which does work but feels very wrong – and what if another message comes in just before I call StopProcessing() – so I have a bool _isProcessing that abandons the message if that happens… and then what if… so maybe adding a lock() on the test/set of _isProcessing… but I’m very conscious of wandering down a smelly code path that I really don’t want to.

As-is, I might as well use ReceiveAndDelete if I have to manually pause listening anyway !

It might well be that the correct solution is to use a ServiceBusReceiver instead of a ServiceBusProcesser, but would prefer not to have to rework it if there is a way to have this one-by-one requirement handled by ServiceBus, rather than me hacking in clumsy workarounds.

Am I asking ServiceBusProcessor to do something is just isn’t designed for, or missing some setting/option, or misunderstanding something fundamental?

The other way to put it is, should I just change over to using a ServiceBusReceiver instead? Then I’d process the message and when I’m done, call the interface to receive another, simple, but with several other components using other queues I built a generic ‘ServiceBusService’ that handles all this and it only uses ServiceBusProcesser – other queues are either used in ReceiveAndDelete mode, or are happy to handle multiple requests in parallel – it’s just this one component that absolutely needs to process one request only at a time and seems a shame to add the ServiceBusReceiver ‘pattern’ to my service class just for this case, unless I need to.