Is it possible to recover messages from error queue automatically?

1

Hi,

Is it possible to recover messages from error queue automatically by code. I have certain requirement to send failed messages to another external application for some specific fallout task. Is it possible?

Regards,
Ripan

2

Hi @ripanpaul,

How our platform works is that we send all messages to a single error queue. We have a tool called ServiceControl that we use to read all those messages and store them in a database. We then have ServicePulse and ServiceInsight that can query ServiceControl for what messages it has and they then visualize all messages. For example ServiceInsight can draw a sequence diagram and flow diagram. But ServicePulse can group messages based on filters and allow you to retry them.

Now ServicePulse doesn’t retry them itself, it asks ServiceControl to do this. What ServiceControl does is look at the header information inside the messages. In there is the endpoint information where it originally came from. It then just sends the messages back.

Of course you can build something like that yourself. If you’re using MSMQ, you can use ReturnToSourceQueue.

Remark

I was a bit triggered by your remark “recover … automatically by code”. Because if you mean that whenever they reach the error queue, that you will immediately retry them, I would advise you not to. For immediate and delayed retries we have recoverability options build in : Recoverability • NServiceBus • Particular Docs

Messages in the error queue are usually a sign something really bad is going on. Either something is offline for a longer period of time, or there is an issue in the system. Like a bug in code, a schema issue in the database, etc. No matter how many times you retry, this won’t solve itself until you fix the issue.

If you immediately retry everything in the error queue, endlessly, the error queue will pile up without anyone noticing. They might always be in transit, because everything is immediately retried. Imagine starting with 5 messages being retried in an endless loop. This will become 10, 25, 100 and eventually 1000 messages. They are all immediately send to the ‘correct’ queue again, meaning that all good messages that should normally immediately be processed, will have to wait until those 1000 messages are retried again by immediate and delayed retries. After this has happened, they will immediately again but put in this ‘correct’ queue by your code.

I’m not totally sure it’s what you mean, but I highly recommend you leave them in the error queue and investigate what to do. Or use our platform with ServiceControl and ServicePulse. Or build something similar yourself, although the time and money spent on that will probably justify buying the license for out complete platform. Multiple times.

1 Like