A Couple of Bugs (or not)

A couple of niggles have come to light today. The first one is that Windows Azure does not seem to support the latest version of the Azure .NET Services Bus. The recent release of the .NET Services SDK, the July CTP, included a new version of Microsoft.ServiceBus.dll (0.16.0.0). This version is not available on Windows Azure. After I had updated my SDK I rebuilt and redeployed a Windows Azure cloud application with a Web Role that calls service bus endpoints. This started throwing all kinds of odd exceptions which was confusing as it (of course) worked fine on my machine. I eventually tracked the issue down and the only way round it at the moment is to set the Copy Local property in the properties of the reference to Microsoft.ServiceBus.dll to true. That way it will get deployed with the application.

The second issue was a kind of two in one. I’m developing some prototypes for Windows Mobile using the .NET Compact Framework 3.5. One of the things I’m working on is a method of keeping mobile devices synchronised via .Net Service Bus queues and routers. There is no native support for the Service Bus on .NETCF but fortunately I only need to make REST calls using a meteor pattern to poll a queue for sync messages.

I had two problems. The first was that I could only poll a queue twice using HttpWebRequest before I’d start getting timeouts. This turned out to be because I was hitting the max connections limit (2 by default), even though I was carefully disposing of responses and closing response streams etc. The second was that I would always get an ObjectDisposedException at System.Threading.WaitHandle.CheckResultInternal when I closed the application. The polling of the queue was of course being done on a background thread, so looking at the two together it did seem that some resource was not being correctly released somewhere.

Looking into the stack trace of the ObjectDisposedException exception I could see references to HttpWebRequest and stream writes. It occurred to me that because I was using REST I was only ever sending headers in my HttpWebRequests, and no body. When I was calling WebRequest.Create() it was possible that the request stream was being opened and because I wasn’t using it it never got closed. As these requests were being created on my background thread they would not dispose correctly and they would continue to consume connection resources and possibly casue thread termination exceptions.

The answer was to close the request stream before sending the request :

try{    HttpWebRequest dequeueRequest = (HttpWebRequest)WebRequest.Create(_QueueHeadUri.AbsoluteUri + "?encoding=asreply&maxmessages=1&timeout=15");    dequeueRequest.ConnectionGroupName = "queueclient";    dequeueRequest.Method = "DELETE";    dequeueRequest.Timeout = 30000;    dequeueRequest.ContentLength = 0;    dequeueRequest.Headers.Add("X-MS-Identity-Token", this._AccessToken);    // this next line is the key     dequeueRequest.GetRequestStream().Close();    using (HttpWebResponse response = (HttpWebResponse)dequeueRequest.GetResponse())    {        if (response.StatusCode == HttpStatusCode.OK)        {            string viaString = response.Headers["X-REQUEST-HTTP-URI"];            Uri viaUri = new Uri(viaString);            if (this.OnMessageDequeued != null)            {                this.OnMessageDequeued(this, viaUri.Query);            }            continue;        }        if (response.StatusCode == HttpStatusCode.NoContent)        {            continue;        }        if (this.OnMessageDequeueError != null)        {            this.OnMessageDequeueError(this, new Exception(string.Format("HTTP Status Code : {0} : {1}", ((int)response.StatusCode), response.StatusCode)));        }    }}catch (Exception ex){    if (this.OnMessageDequeueError != null)    {        this.OnMessageDequeueError(this, ex);    }}
Advertisements

3 Responses to A Couple of Bugs (or not)

  1. Brent says:

    Bert, I don\’t believe the copy local issue is specific to the July CTP. If I recall the conversations form the MSDN forums, its because the VM\’s for hosting applications in Azure are built with .NET 3.5. And since the Service Bus assembly current exists outside of that version of the framework, you have to deploy it as part of your application.Ideally, it would be nice if it was already included (hopefully it will be soon), but meanwhile you have to do the copy local or otherwise include the file as part of your assembly.

  2. Bert says:

    Thanks Brent. I had guessed much. The problem is that the DevFabric gets updated when I update my machine and Azure does not so stuff that works in the DevFabric will not on Azure. It would be useful if the DevFabric somehow stayed sandboxed on my machine so that I could be sure that stuff that worked there would work on Azure.

  3. Brent says:

    I agree Bert. Hopefully things will settle down a bit with that once Azure goes public. A bigger concern to me currently is management of shared development environments for more complex solutions. Given the current SDK limitations (one project in debug at a time), developing more complex solutions will likely require a mixing local and hosted systems. When you start spreading that development load amoung a team of developers, managing each developers environment could be messy and expensive.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: