So the last two weeks have been fairly “code lite”, my apologies. Work has had me slammed the last 6 weeks or so and it was finally catching up with me. I took this week off (aka minimal conference calls/meetings), but today my phone is off, and I have NOTHING on my calendar. So I finally wanted to turn my hand to a more technical blog post.
When not architecting cloud solutions or writing code for clients, I’ve been leading Azure training. Something that usually comes up, and I make a point of diving into fairly well, its how to be aware of changes in a service’s environment. In the pre 1.3 SDK days, the default role entry points always had a method in them to handle configuration changes. But since that has gone away and we have the ability to use startup scripts, not as much attention gets paid to these things. So today we’ll review it and call out a few examples.
Yeah for code samples!
Methods and Events
There are two groups of hooks that allow us to respond to events or changes in role state/status; methods declared in the the RoleEntryPoint class and events in the RoleEnvironment class.But before we dive into these two, we should understand the lifecycle of a role instance.
According to an excellent post by the azure team from earlier this year, the sequence of events in role instances we can respond to are, OnStart, Changing, Changed, Stopping, and OnStop. I’ll add two items to this, Run, which follows OnStart, and StatusCheck which is used by the Azure agent to determine if the instance is “ready” to receive requests from the load balancer, or is “busy”.
So lets walk through all these one by one.
OnStart is where it all begins. When a role instance is started the Azure Agent will reflect over the role’s primary assembly and upon finding a class that inherits from RoleEntryPoint, it will call that class’s OnStart method. Now by default, that method will usually look like this:
public override bool OnStart()
{
// Set the maximum number of concurrent connections ServicePointManager.DefaultConnectionLimit = 12;
// For information on handling configuration changes
// see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.
return base.OnStart();
}
And if we created a WorkerRole, we’ll also have a default Run method that looks like this:
public override void Run()
{
// This is a sample worker implementation. Replace with your logic. Trace.WriteLine(
"WorkerRole1 entry point called",
"Information");
while (true)
{
Thread.Sleep(10000);
Trace.WriteLine("Working", "Information");
}
}
The Run will be called after the OnStart. But here is a curveball, we can add a Run method to a webrole and it will be called by the Azure Agent.
Next up, we have the OnStop method.
public override void OnStop()
{
try
{
// Add code here that runs when the role instance is to be stopped
}
catch (Exception e)
{
Trace.WriteLine("Exception during OnStop: " + e.ToString());
// Take other action as needed.
}
}
This method is a great place to try and allow our instance to shut down in a controlled and graceful manner. The catch is that we can’t take more than 30 seconds or the instance will be shut down hard. So anything we’re going to do, we’ll need to do quickly.
We do have another opportunity to start handling shut down. the RoleEnvironment.Stopping event. This is called once the instance has been taken out of the load balancer, but isn’t called when the guest VM is rebooted. Because this is an event, we have to create not just the event handler, but also wire it up:
RoleEnvironment.Stopping += RoleEnvironmentStopping;
private void RoleEnvironmentStopping(object sender, RoleEnvironmentStoppingEventArgs e)
{
// Add code that is run when the role instance is being stopped
}
Now related to the load balancer, and another event we can handle is the StatusCheck. This can be used to tell the Agent if the role instance should or shouldn’t get requests from the load balancer.
RoleEnvironment.StatusCheck += RoleEnvironmentStatusCheck;
// Use the busy object to indicate that the status
// of the role instance must be Busy
private volatile bool busy = false;
private void RoleEnvironmentStatusCheck(object sender, RoleInstanceStatusCheckEventArgs e)
{
if (this.busy)
e.SetBusy();
}
But we’re not done yet…
Handling Environment Changes
Now there are two more events we can handle, Changing and Changed. These events are ideal for handling changes to the service configuration. We can optionally decide to restart our role instance by setting the event’s RoleEnvironmentChangingEventArgs.Cancel property to true during the Changing event.
RoleEnvironment.Changing += RoleEnvironmentChanging;
private void RoleEnvironmentChanging(object sender, RoleEnvironmentChangingEventArgs e)
{
}
RoleEnvironment.Changed += RoleEnvironmentChanged;
private void RoleEnvironmentChanged(object sender, RoleEnvironmentChangedEventArgs e)
{
}
The real value in both these is detecting and handling changes. If we just want to iterate through changes, we can put in a code block like this:
// Get the list of configuration changes var settingChanges = e.Changes.OfType<
RoleEnvironmentConfigurationSettingChange>();
foreach (var settingChange in settingChanges)
{
var message = "Setting: " + settingChange.ConfigurationSettingName;
Trace.WriteLine(message, "Information");
}
If you wanted to only handle Topology changes (say a role instance being added or removed), you would use a snippet like this:
// topology changes
var changes = from ch in e.Changes.OfType<RoleEnvironmentTopologyChange>()
where ch.RoleName == RoleEnvironment.CurrentRoleInstance.Role.Name
select ch;
if (changes.Any())
{
// Topology change occurred in the current role
}
else
{
// Topology change occurred in a different role
}
Lastly, there are times where you may only be updating a configuration setting If you want to test for this, then we’d use a snippet like this:
if ((e.Changes.Any(change => change is RoleEnvironmentConfigurationSettingChange)))
{
e.Cancel = true; // don't recycle the role
}
Discovery of the RoleEntryPoint
This all said, there are two common questions that come up: how does Azure find the entry point and can I set up a common entry point to be used by multiple roles? I’ll address the later first.
The easiest way I’ve found to create a shared RoleEntryPoint is to set it up in its own class library, then add a reference to that library to all role instances. In each role instance, change their default RoleEntryPoints to inherit from the shared class. Simple enough to set up (takes less than 5 minutes) and easy for anyone used to doing object oriented programming to wrap their heads around.
The first question, about discovery is a bit more complicated. If you read through that entire thread, you’ll find references to a “targets” file and the cloud service project. Prior to the new 1.5 SDK, this was true. But 1.5 introduced an update to the Web and Worker role schemas, a new element that we can use to specify the assembly to be searched for the RoleEntryPoint, NetFxEntryPoint. Using this, you can point directly to an assembly that contains the RoleEntryPoint.
Both approaches work, so use the one that best fits your needs.
And now we exit…
Everything I’ve put in this post is available in the MSDN files. So I haven’t really built anything new here. But what I have done is create a new Cloud Service project that contains all the methods and events and even demonstrates the inheritance approach for a shared entry point. It’s a nice reference project that you can copy/paste from when you need examples without having to hunt through MSDN. You can download it from here.
That’s all for this week. So until next time!
Brent's Notepad 