Strange issue of Diagnostics

Issue: After upgrading Windows Azure Storage to 2.0, the diagnostics work properly when running the Azure project locally, but when deployed, the

CloudConfigurationManager.GetSetting("StorageConnectionString");

returned an empty string. The requirement was to add/ update a timestamp in one of the Azure tables on start  of the Web role. This line was a part of the code to get the connection string for the storage in which the table existed. Since it returned an empty string, the role would get recycled continuously.

Resolution: 
1. Upgrade the project
    Right-click the project, select "Properties". If it is not upgraded to Windows Azure SDK 
    2.0, VS 2012 will prompt you to upgrade to SDK 2.0. In case you have already upgraded
    the project to SDK 2.0, you will see the following screen...
   

2. Update the Microsoft.WindowsAzure.Configuration.dll
    If you have already upgraded to SDK 2.0, then the issue is that the version of the  
    Microsoft.WindowsAzure.Configuration.dll is lesser that 2.0, say 1.7 or 1.8. Just update it to 2.0 using 
    NuGet and you're set to rock 'n roll!!!

PS: Whenever you upgrade to Windows Azure SDK 2.0, make sure that all the dlls with Microsoft.WindowsAzure.* are upgraded to version 2.0
- Microsoft.WindowsAzure.Configuration
- Microsoft.WindowsAzure.Diagnostics
- Microsoft.WindowsAzure.ServiceRuntime
- Microsoft.WindowsAzure.Storage (Make sure you remove  
  Microsoft.WindowsAzure.StorageClient,  which is the older version of 
  Microsoft.WindowsAzure.Storage)

Issue: Role instance doesn't even hit OnStart

Issue: In a Windows Azure app, some time it is seen that the role doesn't even start. On observing the VM on the Emulator, these statements are seen:

[fabric] Role Instance: deployment18(1424).PremierWorker.BackgroundWorker.0
[fabric] Role state Busy
[Diagnostics]: UpdateState(Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorStartupInfo, Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorConfiguration, )
[Diagnostics]: Acquired mutex
[Diagnostics]: Creating config channel server
[MonAgentHost] Output: Agent will exit when WADDM-ShutDown-6628f4899c2a4eeb9dc0ce93dca7aebc is signaled.
[MonAgentHost] Output: Will signal WADM-StartUp-6628f4899c2a4eeb9dc0ce93dca7aebc after the agent is initialized.
[MonAgentHost] Output: Registered as an event consumer.
[MonAgentHost] Output: Agent will exit when parent process 7544 exits.
[MonAgentHost] Output: Monitoring Agent Started
[Diagnostics]: Starting configuration channel polling
[runtime] Role entrypoint . CALLING   OnStart()
[runtime] Role entrypoint . COMPLETED OnStart()
[runtime] Role entrypoint . CALLING   Run()
[runtime] Role entrypoint . COMPLETED Run() ==> ROLE RECYCLING INITIATED
[runtime] Role instance recycling is starting
[runtime] Role entrypoint . CALLING   OnStop()
[runtime] Role entrypoint . COMPLETED OnStop()
[fabric] Role state Destroyed

Solution: After trying out everything on the net, it was finally understood that the issue was caused solely because we had upgraded from Windows Azure 1.8 to 2.0, but the Azure project wasn't upgraded.

To upgrade it, simply right-click the Azure solution, select "Properties" and then hit the Upgrade button on the screen displayed. :)

500 Internal server error

Issue: When deploying an MVC 4, Azure based site, my team always used to get the exception "500: Internal Server Error".

Resolution: After a long time, we got the problem. The issue was in the web role on which the site was hosted. In this web role, the OnRun method was overriden, but it was empty.

Just replacing it by the following code got the issue resolved! :)

Apparently, the issue was that once the role started running, it had nothing to do and so the role would exit, hence causing the application deployed on it to crash.
Another way of taking care of this issue is to add a sleep in a while(true) statement, if you do not want to invoke the base.Run().

Top 10 Uses For A Message Queue

We’ve
been working with, building, and evangelising message queues for the last year,
and it’s no secret that we think they’re awesome. We believe message queues are
a vital component to any architecture or application, and here are ten reasons
why:

1. Decoupling
It’s extremely difficult to predict, at the start of a project, what the future needs
of the project will be. By introducing a layer in between processes, message
queues create an implicit, data-based interface that both processes implement.
This allows you to extend and modify these processes independently, by simply
ensuring they adhere to the same interface
requirements.

2. Redundancy 
Sometimes processes fail when processing data. Unless that data is persisted, it’s lost
forever. Queues mitigate this by persisting data until it has been fully
processed. The put-get-delete paradigm, which many message queues use, requires
a process to explicitly indicate that it has finished processing a message
before the message is removed from the queue, ensuring your data is kept safe
until you’re done with it.

3. Scalability Because message queues decouple your processes, it’s easy to scale up the rate with
which messages are added to the queue or processed; simply add another process.
No code needs to be changed, no configurations need to be tweaked. Scaling is as
simple as adding more power.
4. Elasticity & Spikability
When your application hits the front page of Hacker News, you’re going to see unusual
levels of traffic. Your application needs to be able to keep functioning with
this increased load, but the traffic is anomaly, not the standard; it’s wasteful
to have enough resources on standby to handle these spikes. Message queues will
allow beleaguered components to struggle through the increased load, instead of
getting overloaded with requests and failing completely. Check out our Spikability
blog post
for more information about this.
5. Resiliency
When part of your architecture fails, it doesn’t need to take the entire system down
with it. Message queues decouple processes, so if a process that is processing
messages from the queue fails, messages can still be added to the queue to be
processed when the system recovers. This ability to accept requests that will be
retried or processed at a later date is often the difference between an
inconvenienced customer and a frustrated customer.

6. Delivery Guarantees
The redundancy provided by message queues guarantees that a
message will be processed eventually, so long as a process is reading the queue.
On top of that, IronMQ provides an only-delivered-once guarantee. No matter how
many processes are pulling data from the queue, each message will only be
processed a single time. This is made possible because retrieving a message
"reserves" that message, temporarily removing it from the queue. Unless the
client specifically states that it's finished with that message, the message
will be placed back on the queue to be processed after a configurable amount of
time.

7. Ordering Guarantees
In a lot of situations, the order with which data is processed is important. Message queues are inherently ordered, and capable of providing guarantees that data will be processed in a specific order. IronMQ guarantees that messages will be processed using FIFO (first in, first out), so
the order in which messages are placed on a queue is the order in which they'll
be retrieved from it.

8. Buffering In any non-trivial system, there are going to be components that require different
processing times. For example, it takes less time to upload an image than it
does to apply a filter to it. Message queues help these tasks operate at peak
efficiency by offering a buffer layer--the process writing to the queue can
write as fast as it’s able to, instead of being constrained by the readiness of
the process reading from the queue. This buffer helps control and optimise the
speed with which data flows through your system.

9. Understanding Data Flow
In a distributed system, getting an overall sense of how long user actions take to complete and why is a huge problem. Message queues, through the rate with which they are processed, help to easily identify under-performing processes or areas where the data flow is not optimal.

10. Asynchronous Communication
A lot of times, you don’t want to or need to process a message immediately. Message queues enable asynchronous processing, which allows you to put a message on the queue without processing it immediately. Queue up as many messages as you like, then process them at your
leisure.

We believe these ten reasons make queues the best form of communication between
processes or applications. We’ve spent a year building and learning from IronMQ,
and our customers are doing amazing things with message queues. Queues are the
key to the powerful, distributed applications that can leverage all the power
that the cloud has to offer.

Disclaimer: This is not an original post. It is taken from http://blog.iron.io/2012/12/top-10-uses-for-message-queue.html

The "Could Not Load File or Assembly" exception

Many a times, when one has to start building up on a cloud project, this exception is faced. The scenario goes like this.

I take the latest version of the code from the repository and build it. On build it gives me the following exception.

The reason for this exception is that the solution was previously built using old dlls eg. dlls of the SDK 1.4. Probably when it was built this was the latest version available, but on your machine you have the updated ones in your GAC, say dlls of the SDK 1.7.

Till Windows SDK version 1.6, the required assemblies were stored at:
C:\Program Files\Windows Azure SDK\v1.6\ref

For the SDK version 1.7, the assemblies are stored at:
C:\Program Files\Microsoft SDKs\Windows Azure\.NET SDK\2012-06\ref

Ok.Back to the exception. You just have to follow these simple steps:

1.  Clean the solution.

2.  In the 'References' folder, remove the reference of the old 

    version and add reference of the new version of the dll.

    In case of the StorageClient.dll, make sure you update the 
    references of the other related dlls too. i.e. 
    Microsoft.WindowsAzure.ServiceRuntime.dll and 
    Microsoft.WindowsAzure.Diagnostics.dll

3.  In all the config files (web.config & app.config), make sure to
    change the versions in places like:

    to

That's it! In 3 simple steps, you're ready to go! Build the project now and it executes just fine! :)