Recently I see a lot of questions with that description around Windows Azure Forums. There is one particular reason that appears to be causing this behaviour in most of the cases. I want to describe it with respect to Web Role and Worker Role
Web Role
If you have a web role prepared for Windows Azure deployment be sure that you double check that you have set “Copy Local” attribute to TRUE for any third party assemblies that you reference in your project. These are all assemblies that are not part of Microsoft .NET Framework 3.5 SP1. Such as Microsoft ReportViewer, Microsoft MVC, Microsoft WCF RIA Services, Unity, nHibernate, SandCastle. Any.
Worker Role
While requirements for referenced assemblies in Worker roles are same as requirements for these in Web Roles, there is another important point to observe. And this is that your Run() method should never end. If it ends, than Windows Azure Fabric thinks there is something wrong are recycles your role. That’s why you initial Run method will look like this:
1 public override void Run()
2 {
3 // This is a sample worker implementation. Replace with your logic.
4 Trace.WriteLine("WorkerRole2 entry point called", "Information");
5
6 while (true)
7 {
8 Thread.Sleep(10000);
9 Trace.WriteLine("Working", "Information");
10 }
11 }
It is important to not remove the while (true) cycle as it it the “lifecycle” of our worker role. If we remove it,our worker role will enter an endless loop of:
[runtime] Role entrypoint . COMPLETED OnStart()
[runtime] Role entrypoint . CALLING Run()
Information: Worker Process entry point called
[runtime] Role entrypoint . COMPLETED Run() ==> ROLE RECYCLING INITIATED
[runtime] Role instance recycling is starting
Information: ...
Information: ...
[fabric] Role state Recycle
[fabric] Role state Stopping
[fabric] Role state Stopped
[fabric] Role state Stopping
[fabric] Role state Stopped
[fabric] Role state Suspended
[fabric] Role state Aborted
[fabric] Role state Teardown
[fabric] Role state Destroyed
[fabric] Role state Created
[fabric] Role state Suspended
Why is it so is well described by Steve Marx as answer to my question on MSDN Forums:
The model is that you're expected to never return from Run(). (If you do, we think something went wrong and restart you.)
If you have other threads doing work, you can just go into an infinite sleep at the bottom of Run(). (Thread.Sleep(Timeout.Infinite))
I really hope that this post will save you lot of time and frustration using Windows Azure.
5 comments:
i am facing the same problem. i have tried what you suggested in this blog post but still it's getting aborted. thanks neways!
- http://www.parasdoshi.com
It's a long time ago. But i was able to solve the problem later - and i think it was related to attaching a x86 library instead of x64. Not entirely sure though - but something on that line.
Thanks Dude.... :):):)
Thanks Dude.. It works as a charm :):):)
you saved my day thanks
Post a Comment