EndpointHeartbeat ending up in DLQ

1

NServiceBus 5.2.24
ServiceControl.Plugin.Nsb5.Heartbeat

We’ve disabled the usage of DLQ thru code by configuring the MSMQ connection string:

var transport = configuration.UseTransport<MsmqTransport>();
transport.ConnectionString("journal=false;deadLetter=false;");

and everything seems fine except for the EndpointHeartbeat messages sent to SC which end up in the transactional DLQ anyway when SC is stopped.

2

Is the endpoint sending the heartbeats on the same machine as the ServiceControl instance it is trying to connect to, or a different one?

If they are on different machines, which machine’s DLQ does the heartbeat message end up getting stuck in?

3

SC in running on its own machine, and the error messages were in the local transactional DLQ of the sending endpoint.

But I cannot reproduce this anymore after restarting the machines where the endpoints are installed. Maybe the connection was cache? I’ll reopen this if I notice the same behavior again.

Thanks.

4

My first thought would be that MSMQ could not send the heartbeat messages the other machine. If that takes too long, the messages in the Outgoing Queue won’t be delivered at the other machine, the one where Service Control is installed on, and MSMQ will eventually move them to the DLQ.

I’m not 100% sure if disabling the DLQ would disable that feature (moving undeliverable messages in outgoing queue to dlq) in MSMQ, though. Would need to verify that.