Ben's Quarters adventures in application development ...

The advances in VM technology for both client and server operating systems is obviously a great thing.  It saves money, time and makes life much easier when you can just copy an image to a different machine, make backup copies of an image and go back to an old image in a very small amount of time.  It's great too for having software testing environments.

One significant downside to this technology is going to be the amount of legacy software that will stick around.  By software, I mean operating systems and applications.  Upgrading or moving to a different OS or app is always a hassle.  However, one common opportunity when switching to a newer OS or app makes sense is when replacing old hardware.  Before VMs entered the scene, you might traditionally buy a new workstation or server every 4 years, for example.  A new machine means re-installing the OS and applications.  What a perfect opportunity to start off the new machine by installing the latest OS and applications.

With VM technology, when a physical machine needs to be replaced, if the OS on it is already a VM, you just copy that VM to the new hardware.  Even if the old system isn't a VM, no problem.  There's tools available to create a VM from a physical instance of an OS.  Once the old physical instance of an OS is a VM, you just copy that VM over to the new hardware.  So you end up with a brand new machine, but the old OS and old applications are still running on that machine.

For software companies, this means their customers may demand they support older versions of their software for a longer period.  When building new versions of software, it may also be necessary to include support for older operating systems based on the number of existing or potential customers who are still running an old OS.

A client of mine just recently needed to replace their 8 year old server.  It's a Windows 2000 terminal server that several employees work out of.  I've convinced some of the employees to start using Firefox, but others are still stuck on IE6.  The client ended up converting the physical Win2K server to a virtual server and copied that over to the new hardware.  Ack!  There's that growing movement in the community to persuade people to get off IE6.  I think the statistics show the percentage of IE6 users out there is still in the 15% - 25% range.  That's much too high a demographic to desert and not support when building a website.  Unfortunately, IE7/IE8 isn't available for Windows 2000.  For this particular client, I just need to convince everyone there to start using Firefox.  Maybe I can just hide the IE6 icon on their desktops :)

IE6 is a classic example of software you want everyone to get off of, and bury as deep as possible.  It's definitely not the only software out there that should be moved away from as newer versions of subpar software are released.  This increase in legacy software still being used out there is one of the few downsides to this overall great virtualization technology.

The caching of data in BlogEngine.NET becomes a problem when BE.NET is installed in a web farm.  When you add, edit or delete a post, that change is occurring on one machine within the farm as well as within the data store (App_Data or DB).  But the other servers within the farm are unaware there’s been a change in data.  Not until the data loaded in memory on these other servers clears out anywhere from minutes to hours to days later, the old set of data will continue to be shown to visitors hitting one of these other servers.

I created a WebFarm extension which may help some people in this situation.  I haven’t worked much with web farms, so I’m not sure how well this extension will work.  Any feedback is appreciated.  I was able to test this extension on Vista/IIS7 where I had two separate web applications pointing to the same physical BE.NET location on my machine.  Even in this situation, creating a new post within one application would normally result in the post NOT showing up in the other application.  This new Web Farm extension did solve the caching problem for this scenario.  I’m hoping this success will carry over to a Web Farm scenario.

There’s two files in the ZIP file download.  WebFarm.cs should go in the App_Code\Extensions folder.  The other file, webfarm_data_update_listener.ashx, should go in the root of your blog.

Once those files are in their correct locations, if you go to the Extensions tab in the control panel, you’ll want to click ‘Edit’ for this new WebFarm extension.

I wanted the help box on the right side to include as much information as possible.  But as you can see, the Extensions page doesn’t currently handle long description boxes very well :)

The idea behind this extension is that if each server within the farm has a unique internal Ip address, this extension can notify each server that a change in data has occurred.  Not knowing a lot about web farms, this is the part I’m unsure is possible.  But it does some reasonable each server would have its own unique IP address.  If you’re using host headers, this extension may not work for you – unless you have a unique URL to each server within the farm.

The extension currently notifies the servers in the web farm when a new post or page has been created, updated or deleted.  Other data such as Settings, Profiles, Categories, Comments, etc. is not handled by this extension.  Or at least not in this version.

The webfarm_data_update_listener.ashx file you placed in the root of the blog is the handler that receives notifications when a change in Post or Pages has occurred.  The data passed to the handler includes the type of data changed (Post, Page), the type of change (Insert, Update, Deletion) and the ID of the Post or Page that has been inserted/updated/deleted.  Rather than the handler re-loading all the Post/Page data, it will insert, update or delete just the one piece of data that changed.  This is more efficient than re-loading all the data which could be taxing for those with a lot of blog data.

As described in the help area when adding the server Ip/Urls in the WebFarm extension, make sure the “Shared Key” you enter matches the key in the webfarm_data_update_listener.ashx handler file.  The default key in the handler is “blogengine”.  For security purposes, you may change the key in the ASHX handler.  But be sure the ASHX key matches the key you enter for each Ip/Url.

Also, because of this same data caching issue in web farms, after you enter all the web farm server Ip addresses into the WebFarm extension, you’ll want to re-start BE.NET so the extension data you just entered is detected by all the servers in your farm.  Updating the web.config file with any meaningless change will accomplish re-starting the blog application.  This is just a one-time requirement so all servers have the list of servers they need to notify when a post or page change has occurred.

I realize this extension has its limitations and isn’t a comprehensive solution to undesired caching in a web farm scenario.  But it does handle propagating changes in posts across the servers in the farm – one of the more important areas.  This extension is also easy to get started with in contrast to making various changes within BE.NET itself.  Again, any feedback on this extension is appreciated.

Download: WebFarmExtension_1.0.zip (3.26 kb)