I hacked another fix into CruiseControl.Net today and we now almost have an acceptable level of performance in my particular (some may say warped) circumstances. The trick was to hack the project trigger to be a “local project” trigger. By default the project trigger uses .Net remoting to talk to the CruiseControl.Net server where the project is hosted. In my case this meant that all of my project triggers (and there are lots!
I am intending to check out some of the other build servers that people have been suggesting, but today I was too busy with real work so I just left a cut down version of my latest CruiseControl.Net configuration running on one of my boxes and fixed a few issues whilst doing proper work most of the time… This evening I decided to go and look at why CruiseControl.Net scales so poorly and the first issue that I came across is the title of this blog posting…
I’ve almost got something that works out of CruiseControl.Net. Once I’d hacked in some fixes for the project triggers and other stuff that didn’t work the way I wanted it to I concentrated on generating the config files that I required and testing the system.
The good news is that I now have an integration system that works, it can build, test and deploy libraries in such a way that dependent libraries and applications are rebuilt as new versions of deployed artifacts become available.
I’ve been trying to get my code to build with CruiseControl.Net this week. It’s taken longer than I’d hoped, but I’m almost there. It became easier when I switched from assuming various parts of CruiseControl.Net would “work as I expected them to” to assuming that I’d have to delve into the source and change things…
On the whole I’m a bit disappointed in CruiseControl.Net. I’m sure it works very nicely for simple situations, such as where you pull everything out of your repository and build it with a single project, but, when you’re trying to do more complex things it seems to be a bit fragile.
I’m currently working on two new releases of The Server Framework, the first is a simple release to add support for VS2008 and the second is the next “feature” release. Due to the number of projects and example servers and supported compilers that I test with it can take some time to finalise a release; each example server has to be checked out, built in each build configuration with each supported compiler and then the tests need to be run… Last time I did this I had planned to put aside some time to sort out an automatic build to do it for me, this time I might actually do it…
One of the problems with iterative development of servers that include performance counters is that it’s quite easy for the counters that are installed on a machine to get out of sync with the counters that the server is actually compiled to use. As development progresses and new counters are added the counter dll needs to be uninstalled and then reinstalled so that the text strings associated with the counters remain in sync.
I picked up a book yesterday, Writing Secure Code for Windows Vista. Which seemed quite interesting, and was a nice slim volume that would slip into my hand luggage for my flight to Geneva on Friday night (yay first ski weekend of the season!). I’ve been flicking through it this evening and was interested in the “Standard Annotation Language” (SAL) for annotating unmanaged functions that muck around with memory buffers, it looked like a potentially easy adjustment to The Server Framework code which would possibly improve security and usability… Unfortunately it seems that SAL is only operational when you run with the /analyze compiler switch and that’s only available if you’re running an ’enterprise’ level of Visual Studio…
I removed the last version of “Norton Anti-Virus” (and all of the other stuff that I’ve been upgraded into over the years) from the last of my machines yesterday. I’ve replaced it with AVG, currently the free version to test it out.
All of the machines feel more sprightly and run faster. One of my old laptops which is now only used for fire-side web browsing is now actually usable again!
One of my current clients has got me drifting back towards my Investment Banking roots by developing an Excel addin for them. Luckily for me it’s a banking client with a twist compared to my previous banking clients; they’re happy for me to work as an external consultant, doing most of the work from my office at home and working on my contract terms.
The development work so far has been quite interesting.
I’m currently fixing a bug in the UDP side of The Server Framework. The problem is that I’m failing to handle how Winsock reacts when an overlapped SendTo() results in an ICMP Port Unreachable response from the remote host. This error gets reported by failing a pending WSARecvFrom() on the same socket by returning 0 bytes from the WSARecvFrom() with an error code of ERROR_PORT_UNREACHABLE.
This would be fine if the framework didn’t assume that all errors from an overlapped WSARecvFrom should mean that we don’t post another read… You may recall from when I was doing some work on making the framework survive low resource situations that we can’t just issue another read when the previous one failed due to a low resource situation as we would just continue the problem, so we back off and recover later.
