Fetch messages from dead letter queue (DLQ) and similar queues and manage them in ServiceControl

[andreasohlund]

As Opie I want all messages in the dead letter queues to be imported to ServiceControl so that I can investigate the reason for failure and retry any of these messages if needed

Some messaging infrastructure has dead letter queues. MSMQ, ASB, and likely others. These queues are currently not ingested.

For MSMQ we have a custom check that checks if any messages are in the dead-letter queue but you cannot manage these from ServicePulse/ServiceControl.

Related

• https://github.com/Particular/NServiceBus/issues/383
• https://github.com/Particular/ServicePulse/issues/8
• https://github.com/Particular/LaunchWave.DevOpsAdvancedMonitoring/issues/23
• https://github.com/Particular/ServiceControl/issues/63

[andreasohlund]

@danielmarbach is this relevant for activemq?

[danielmarbach]

I think yes. Because the out of the box tools from ActiveMQ are extremely miserable. It would be nice to see it in the ServiceControl. @remogloor thoughts?

[johnsimons]

I think SqlServer transport should have a DLQ table, for exactly the same reasons all other transports have it!

[andreasohlund]

+1

On Thu, Sep 26, 2013 at 1:49 AM, John Simons notifications@github.comwrote:

I think SqlServer transport should have a DLQ table, for exactly the same reasons all other transports have it!

— Reply to this email directly or view it on GitHubhttps://github.com/Particular/ServiceControl/issues/63#issuecomment-25134162 .

http://andreasohlund.net http://twitter.com/andreasohlund

[andreasohlund]

Can you raise an issue for that John?

On Thu, Sep 26, 2013 at 2:15 PM, Andreas Öhlund andreasohlund2@gmail.comwrote:

+1

On Thu, Sep 26, 2013 at 1:49 AM, John Simons notifications@github.comwrote:

I think SqlServer transport should have a DLQ table, for exactly the same reasons all other transports have it!

— Reply to this email directly or view it on GitHubhttps://github.com/Particular/ServiceControl/issues/63#issuecomment-25134162 .

http://andreasohlund.net http://twitter.com/andreasohlund

http://andreasohlund.net http://twitter.com/andreasohlund

[remogloor]

Yes it is relevant. If for some reason the normal NSB error queue mechanism doesn't kick in messages can end in the DLQ. There are currently situations where this happens and NSB cannot do anything. E.g. an error occurs in the ActiveMQ NMS client e.g. due to connection losses.

[andreasohlund]

https://github.com/Particular/NServiceBus.SqlServer/issues/6

[johnsimons]

Is this still on the table? What milestone?

[danielmarbach]

I second that feature! Very important. Not even @andreasohlund can ignore this because he wrote a blog post about how important it is to monitor DLQ :100:

http://andreasohlund.net/2012/10/25/monitoring-your-dead-letter-queues/

[seanfarmar]

+1

[johnsimons]

@Particular/servicecontrol-maintainers

This issue is 2.5 years old, according to a thread in SP

The blocker is that we need to run as admin in order to read from the local DLQ's in msmq and we currently don't have anything that is running with those priviliges.

I propose we close this one ?

[mauroservienti]

I propose we close this one ?

Let me disagree :-)

what if we could deploy a SC component that runs on its process as Admin and that can talk to SC?

This could be part of the Platform Componentization effort.

[johnsimons]

what if we could deploy a SC component that runs on its process as Admin and that can talk to SC? This could be part of the Platform Componentization effort.

@mauroservienti I am happy to consider that, but at the moment as far as I know there are bigger fish to fry, so do you see us acting on this any time soon ?

[johnsimons]

This is currently not prioritised to be done any time soon, I will close this one for now and if we ever go down this path we can reopen it.