ServerFramework.com is a new website that we’ve put together to make it easier for users and potential users of the licensed version of our high performance, I/O completion port based client/server socket framework to find all of the information that they need. As many of you know, I’ve been working on the code that forms The Server Framework since 2001 and it’s been used by lots of our clients to produce highly scalable, high performance, reliable servers that often run continuously 24/7, all year round.

Back in April I was talking about how the fact that 6.2 allowed you to enable FILE_SKIP_COMPLETION_PORT_ON_SUCCESS meant that some server designs might start to experience recursion that they previously didn’t experience. During the testing for the imminent release of 6.3 I managed to hit on just the right combination of build machine, load and test server to actually produce this under test. As I mentioned back in April, this is only a problem (in 6.

I tend to work with lots of solutions at once. I’m often building code for clients, building and testing new example servers for The Server Framework and running lots of copies of various versions of Visual Studio at once. Now, if I happen to try and open two VS2010 solutions at around the same time (and given the time it takes for VS2010 to start up that’s not that hard to do), then one of them wins and gets my normal settings and one (probably the one that gets a sharing violation whilst trying to read my normal settings) ends up with some default madness setup that isn’t what I want at all.

This evening I kicked off the acceptance tests for version 6.3 of the example servers that ship with The Server Framework; they’ll probably take most of the weekend to run, if I’m lucky. The unit tests for all the libraries have already been run through the build machines over the last few days, the release notes are almost done and so I’m now in the final phase of preparing the 6.

Previously on “Practical Testing”… I’ve been looking at the performance of the timer system that I developed and have built a more specialised and higher performance timer system which is more suitable for some high performance reliable UDP work that I’m doing. Whilst developing the new timer wheel I began to consider the thread contention issues that the timer system faced and came up with a notation for talking about contention (see here).

My previous rant about DevPartner Studio (and especially the BoundsChecker portion of it) resulted in several emails from guys on the development team and a call from product owner at MicroFocus. They pointed me towards the latest ‘web sync’ (service pack) which was released shortly after my rant, explained how the issues I’d noticed had made it through testing and why they existed and commiserated with me over the state of support.

Previously on “Practical Testing”… I’m writing a timer wheel which matches the interface used by my timer queue. This new implementation is designed for a particular usage scenario with the intention of trading space for speed and improving performance of some reliable UDP code. The last entry completed the development of the timer wheel. This time we fix a couple of the bugs that I’ve discovered since I started to integrate the code with the system that it was developed for.

The story so far, I’ve owned DevPartner Studio for several years and been on a support contract the whole time. The support situation went a bit flaky when Compuware sold the product to Micro Focus, I expect that either I’m simply not a big enough client for them to care or their post sales and support is just no where near as good as the Compuware offering. With Compuware I’d be contacted when new versions came out and I had a named sales contact that I could also use for questions, etc.

I’m still considering my options with regards to intrusive containers to replace the STL maps that I’m using in my timer queue implementation. I think I may be able to use the boost::intrusive sets in place of a true map in most of the situations that I need (I just have convince myself that a) it will work with all the compilers that I need to support, b) that adding a dependency to part of boost is a good idea for me and my clients and c) that even though my gut reaction on seeing the code is that it’s pointlessly clever and bound to be a bitch to debug it’s probably better than rolling my own).

Last time I explained how the managed side of my flexible hosting server architecture was structured. I dealt with the IDL required to generate the COM interfaces which were used to communicate between unmanaged code and managed code and detailed how the custom AppDomainManager object allowed me to load and execute managed code in such a way that it was easy to update the managed applications whilst the server was running.