My tangential testing that began with my problems with commands run via WinRs during some distributed load testing are slowly unravelling back to the start. I now have a better build and test system for the server examples that ship as part of The Server Framework. I have a test runner that runs the examples with memory limits to help spot memory leak bugs and a test runner that checks for lock inversions.
As I mentioned, I’ve been adjusting my build system and have finally got to the point where my lock inversion detector is suitable to run on all of my example servers during their test phase on the build machines. I’m working my way through the various example server’s test scripts and adjusting them so that they use the lock inversion detector, can be easily configured to run the full blown deadlock detector and also can run the servers under the memory profiling test runner that I put together earlier in the week.
My theorising about the strange memory related failures that I was experiencing with my distributed testing using WinRS have led me to putting together a test runner that can limit the amount of memory available to a process and terminate it if it exceeds the expected amount. With this in place during my server test runs I can spot the kind of memory leak that slipped through the cracks of my testing and made it into release 6.
I’ve had one of those days. In fact I’ve had one of those days for a couple of days this week…
It started when I decided to improve the profiling that I was doing on a new memory allocator for The Server Framework by extending the perfmon and WinRS based distributed server testing that I wrote about a while back. This allows me to create a set of perfmon logs, start a server to collect data about and then start a remote client to stress the server.
See here for details.
The latest release of The Server Framework is now available from ServerFramework.com. See here for details.
I’ve put together a new website for my super scalable, high performance, I/O Completion Port based server framework.
This has all of the information that you need to decide if you can use The Free Framework or if you’d prefer to license The Server Framework. There’s also a new server example, WASP, which is a pluggable server platform that is available in compiled form and is free for non-commercial use. Over the next few months WASP will evolve to support most of the key features of the various options that are available with The Server Framework such as SSL, Managed hosting, UDP and TCP, etc.
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.
