Azure Service Management REST API HTTP status codes

I am currently working on scripting a complex Azure deployment.

Azure provides a REST API that you can call to perform many tasks. To make this api a bit easier to work with Microsoft released the Azure cmdlets that provide a wrapper for some of this functionality.

It is worth noting that the service api doesn’t allow you to do everything you will want to do. For example a weird omission is that you cannot currently script the creation of storage services.

Anyway I digress!

Whilst creating a wrapper for some of the API calls I ran into a number of issues that I wouldnt want anyone else to waste their time with. The Azure service management API isnt the most descriptive of things when you screw up and most of the time will give you an HTTP status code to indicate what happened.

I love the purist nature of this and it does make sense but surely Microsoft could have included some more info given you have to be authenticated anyway?

Anyway if you are working with the API and having problems here are a few things to check:

401 (unauthorized) – check you haven’t exceeded service deployment allowance, if you are deleting a service slot you will also need to suspend any running roles
403 (forbidden) – check API certificate and that it is uploaded. Note the .net certificate APIs have an additional overload that allows you to only retrieve valid certificates – if you have issues the certificate yourself it wont be valid!
409 (conflict) – service names must be globally unique – check yours is!
500 – check your request is valid

I also noticed that Fiddler seems to interfere with requests and results in 403 Forbidden errors.

Deploying to Azure – The path is too long after being fully qualified. Make sure the full path is less than 260 characters and the directory name is less than 248 characters.

This week I was writing some Powershell scripts to deploy our application to Azure (blog post to follow to save others the trouble of finding out how to do this).

When I deployed this week after the team had been doing some refactoring I got the error:
The path is too long after being fully qualified.  Make sure the full path is less than 260 characters and the directory name is less than 248 characters.

Agrahhh! Ok I’ll admit I am not a big fan of our very long naming convention but even with this none of the paths actually exceed this length. The problem is due to Development Fabric using a temp directory behind the scenes. For a full explanation please see: http://blogs.msdn.com/b/jnak/archive/2010/01/14/windows-azure-path-too-long.aspx

This can be resolved (unless you have really long paths!) by creating an environmental variable called _CSRUN_STATE_DIRECTORY and setting it to a directory such as c:\a\. Azure will then use this temp directory instead that will hopefully get around this issue.

SQL CE and Sync framework – A duplicate value cannot be inserted into a unique index.

I am currently working on a project utilizing Sync Framework and SQL CE and ran into an annoying bug with identity fields that I wanted to make other developers aware of.

If you use sync framework to sync to a SQL CE database and you use identity fields then after the sync has occurred identity fields seed values will be reset to 1 after the sync has occurred.

This means should you then try and insert data into one of these tables you will receive the error “A duplicate value cannot be inserted into a unique index” as SQL CE believes the next value in the identity field is 1.

You can verify this is happening by examining the information_schema view before and after the sync:

select * from information_schema.columns where table_name = <tablename> and column_name = <columnName>

The solution?

Well I spoke to Sync framework team who said they have no plan to fix this issue (unbelievable!) so you have 2 main options:

Do an insert (this will fail) however SQL CE then seems to sort out the correct identity numbering and you are good to go

or

Alter the table and reset the seed value – note SQL CE doesn’t support DBCC CHECK IDENT command:

Foreach table in scope {

@currentId=max(RecordID) from table (Select max(RecordId) As MaxID from [test] )
Reseed current table to @currentId (ALTER TABLE [test] ALTER COLUMN RecordId IDENTITY ([@currentId], 1)
}

Ideally when you are performing synchronization you dont want to be using identity fields (bad things would happen with more than one client!) but probably GUID’s. In our project only one database can be master and we are prevented from making schema changes.

HTML5 support and Javascript perf across different browsers

I am currently putting together a preso on HTML 5 for codecampoz and as part of this evaluated support across different browsers. I also wanted to check on the Javascript performance of a number of different browsers (especially as IE9 came out yesterday) by running various benchmarks. The tables below summarize my findings:

Note that this is a very unscientific study – I only ran the tests once (although some of them repeat themselves anyway) and I had other applications running in the background. Some browsers will also now use hardware acceleration for certain items.

The tests were run on a Dell XPS 16 studio, win7 64 bit, 8gb ram, Intel i7 Q720 at 1.6ghz, ATI Mobility Radeon HD 4670.

Browser HTML5test Sunspider (ms) Kraken (ms) V8v5
IE 8 (8.0.7600.16385) 27 5204.0 119
IE 9 beta (9.0.7930.16406) 96 661.4 61183.0 1328
Firefox (3.6.9) 139 829.4 17924.7 524
Firefox (4.0b6) 204 746.2 11950.6 1008
Chrome (6.0.472.59) 217 588.2 15941.5 6226
Opera (10.62) 159 622.4 13617.3 3916
Safari (5.02 7522.18.5) 207 732.4 18689.6 28

Table 1. Html5Test.com scores and various Javascript benchmarks

As the preso is about using HTML5 I wanted to see which areas could be used across the most browsers. I picked a few areas I would want to make use of the most and the results (again based on HtmlTest.com) are below:

Functionality IE 8 IE 9 beta Firefox Firefox 4 Chrome Opera Safari
Doctype trigger strict Y Y Y Y Y Y Y
Canvas N Y Y Y Y Y Y
Video N Partial Partial Partial Partial Partial Partial
Audio N Partial Partial Partial Partial Partial Partial
Forms N N N Partial Partial Partial Partial
Drag and drop N N Y Y Y N Y
Application Cache N N Y Y Y Y Y
Geo location N N Y Y Y Y Y
Cross document Y Y Y Y Y Y Y
Web sockets N N N Y Y N Y
Session storage Y Y Y Y Y Y Y
Local storage Y Y Y Y Y Y Y
SVG in text N Y N Y N N N
Web workers N N Y Y Y Y Y
Web SQL Db N N N N Y Y Y

Table 2. Support of key HTML 5 elements across browsers

Note that Web SQL db has been dropped in favor of indexed db and all vendors so far have used SQLLite to implement the WebSQLDb.

So in summary from my unscientific tests:

  • Chrome provides best html5 support (in terms of Html5test.com score)
  • Chrome is quickest on Sunspider benchmark but Opera is quickest on Kraken (which utilizes Sunspider)
  • IE8 is massively slower on js benchmarks but IE9 js perf is much improved (the Kraken test wouldn’t even run on IE8 and kept giving dialogue about script running slow)
  • You can use some of the storage stuff if your users browsers are fairly up to date
  • Canvas support is good on latest browsers across the board

Links:

Html5test.com (bonus points ignored)
www2.webkit.org/perf/sunspider-0.9/sunspider.html
krakenbenchmark.mozilla.com
http://v8.googlecode.com/svn/data/benchmarks/v5/run.html