Windows Azure ServiceBus pitfalls

I’m doing a POC (Proof of Concept) with Windows Azure for a big customer. The idea is to have a web site hosted on Windows Azure where managers can enter messages. These message will then be distributed to computers on sites scattered all over the world.  A kind of a messenger service, mainly intended to be used when other systems fail. The messages sent will be something like “To all employees in Australia: Server X is down. Expected back online at 9 pm.”

Now, there are samples and tutorials on the Microsofts Azure website that shows how to build similair systems. So I could just take one of those samples, modify it a little and be done. Piece of cake, right? NOT SO!

There are several pits I fell into during the development.

Pitfall 1
I wrote the system on my development machine, deployed it to Azure and tested it. Works fine! Great! Lets go to the customer and try it!

The client application crashed because the ServiceBus assemblies was not installed on the client machine, thus the “netEventRelayBinding” could not be found. Solution? Add it to the config file:

      <add name="netEventRelayBinding" type="Microsoft.ServiceBus.Configuration.NetEventRelayBindingCollectionElement, Microsoft.ServiceBus, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

The client application crashed again with a ‘Access Denied’ error. Cause? The customer firewall didn’t allow connections on the port the service bus uses.

Solution? Use http/https on port 80/443 instead. Add this to the code:

ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.Http;

Pitfall 3
The application crashed with a “HTTP 407 Proxy Authentication Required” because the customer has an internet proxy that requires authentication.

Add this to the config-file:

  <defaultProxy enable="true" useDefaultCredentials="true"/>

Pitfall 4
The application crashed again with a cryptic error: “Chunked encoding upload is not supported on the HTTP/1.0 protocol”.
I worked together with a network technichian to try to find the problem. After a lot of log reading and head scratching, we have come to the conclusion the proxy thinks that is an unapproperiate site and blocks it, just like facebook and other sites the customer employees shouldn’t access during work.

Solution: Make sure the proxy allows outgoing connections to Azure AppFabric sites. Here’s a list of IP-addresses:

If you are planning on using Windows Azure AppFabric from within a company network, beware of proxies. They may cause a lot of headaches.

Also, I found this to be quite helpful:

This Post Has 2 Comments

  1. Varghese

    Very good

  2. RajaSekar

    Thanks for your post as this covered Proxy authentication. It helped when I couldn’t find help in any of MSDN and Technet sites

Leave a Reply