0
votes

I have an NServiceBus endpoint running on an Azure worker role. I installed the package ServiceControl.Plugin.Nsb5.Heartbeat. When I deploy directly from VS to the cloud service, my endpoint shows up in ServicePulse and I get my heartbeats as expected.

When I go through our automated deployment process, the endpoint isn't detected by servicepulse, and I don't get any heartbeats. (Even if you don't have the heartbeat plugin installed, ServicePulse does detect the endpoint and tells you that that endpoint does not have the heartbeat plugin installed).

When I login through RD, I can see the heartbeat assembly in the approot. My config is the same for both scenario's, but I'll add it here for reference:

In my config appsettings:

<add key="Heartbeat/Interval" value="00:00:01" />
<add key="ServiceControl/Queue" value="xxx.xxx.servicecontrol" />

Rest of my config:

<section name="MessageForwardingInCaseOfFaultConfig" type="NServiceBus.Config.MessageForwardingInCaseOfFaultConfig, NServiceBus.Core" />
<MessageForwardingInCaseOfFaultConfig ErrorQueue="error" />

My ServiceControl instance is running on my local computer and monitoring the correct service bus. The error queue name is set to error, just like in the config, and the error forwarding queue name is set to error.log.

When the workerrole starts, and the NSB is started, I can find this in the logs (which btw is exactly the same as what I can find in the workerrole that is sending out heartbeats):

Name: Heartbeats
Version: 2.0.0
Enabled by Default: Yes
Status: Enabled
Dependencies: None
Startup Tasks: HeartbeatStartup

I have absolutely no clue why the same code is behaving differently. It's the same code, the same config, the same setup, just deployed differently. When comparing deployed assemblies, I can't detect a difference. The heartbeat assembly is there, and it looks like NSB is picking it up as well. I'm just not receiving any heartbeats from that particular endpoint.

Any idea on what I could be missing? Or what I could try to fix this?

Thanks in advance!

1

1 Answers

1
votes

It turns out that both endpoints are sending heartbeats, but ServicePulse shows them as one endpoint.

In ServicePulse I could see one endpoint: Endpoint@MachineA. MachineA was the actual machine name of the worker role instance of my CloudService "Test". I could login to this instance through RD and see NSB's log activating heartbeat functionality. When I deployed through our automated deployment to CloudService "Dev", I got no additional endpoint in ServicePulse. So I decided to delete CloudService "Test" completely.

When I checked ServicePulse, endpoint Endpoint@MachineA was still up and receiving heartbeats every second. I couldn't figure out why since I had just deleted CloudService "Test" with that particular instance.

I decided to rename the endpoint, and deploy through our automated procedure to CloudService "Dev" (so CloudService "Test" does not exist). At that moment I saw the endpoint Endpoint@MachineA go down, and a new EndpointRenamed@MachineX go up, receiving heartbeat messages.

So it was a non-issue in the sense that both my endpoints were sending out heartbeats. The problem lies in the fact that ServicePulse somehow considered them to be the same endpoint. They did have the same name, but they were hosted in a different cloud service on a different machine, which should be translated into another endpoint in ServicePulse.

Hope that helps someone!