0

We have an external SB Topic Subscription for which we are the consumers. We are currently reading the SB with a max concurrent thread count of 20.

I am wondering what would be the best way to occasionally drain the DLQ? Should it be included in the same app or should I create another for just draining the DLQ?

Pointers on any standards being followed would be highly appreciated.

Jim
  • 355
  • 7
  • 20

1 Answers1

2

It depends on what do you mean by "draining the DLQ." Do you need to reprocess those messages or purge the queue? What environment you're running in? Would a serverless option work in your case?

If you don't need those messages and OK with running Functions (e.g. consumption mode), I would do the simplest thing - a Function triggered by DLQ that does nothing. That's right, nothing. That will do the job and purge those messages as they arrive w/o the need to worry about hosting your process, scaling out, concurrency, etc.

Note that a dead-letter queue is always a sub-queue on the original queue. For a queue named myQueue the dead-letter queue would be myQueue/$DeadLetterQueue.

Sean Feldman
  • 23,443
  • 7
  • 55
  • 80
  • Sorry about the ambiguity! As we are the consumers, by draining the DLQ, I meant receiving the message, logging and reprocessing. And irrespective of the process failure, I need to mark them complete finally post logging an exception. – Jim Apr 26 '21 at 19:16
  • 1
    Ok, so not quite draining I'd still go with Azure Functions, completing the incoming DLQ-ed message once the re-processing is successful. – Sean Feldman Apr 26 '21 at 19:50