We have this little XML file called redirect.config which contains details of dead links in our app. and the corresponding new ‘live’ link that should be served in its place.
Our Web Content team was saying that updates to this file were not being recognised by the app. I mucked around with the file for a while checking format, making sure the xml was well-formed, then I deleted my Browser cache, stripped out all records in the XML file except the new (non-working) one but alas nothing worked. Also, existing redirections still worked although the redirection.config was empty except for one record. Then I restored the file to its original state and, although in practice I had changed nothing, the redirection suddenly kicked in.
Puzzling, but the problem was now out of my hair – until today, when the problem recurred on a different domain and stubbornly stayed there. So I had to figure it out for real. I went to lunch thinking, ‘Something is cached. I’ll restart the Application Pool on the Web Server’.
When I got back, from lunch the redirections were working. My colleague told me she has restarted the Application Pool but didn’t know why it worked.
Investigating the problem properly for a change I found the redirect.config file was being read by a method which was invoked during IHTTPModule.Init. Yes, the config file (really just an xml data file) was being used as data for a custom HTTPModule and was being read during HTTPModule Initialisation. So, when is a HTTPModule Initialised ? Here’s a great link ‘IHttpModule Gotchas’ by UK Programming legend Dominic Pettifer which explains all.
The basic deal is that the .NET runtime will create a certain number of HTTPApplication objects on Application startup. It keeps these in a pool. For each HTTPApplication object, .NET runtime creates an instance of each custom HTTPModule registered in the web.config. That’s when IHTTPModule.Init is called. When a HTTPRequest comes in, that Request is served by one of the HTTPApplication Objects in the Pool which is then put back in the Pool.
The consequence for me is that updates to my redirect.config file are never read until a new HTTPApplication object is created and therefore a new instance of my HTTPModule is created. So I was basically correct. The redirect data was being cached – inside the pooled HTTP Application objects.
The fix – re-create the Application Pool.
And that’s why my redirects started working out of nowhere: the .NET Runtime according to its internal algorithms decided to create a new instance of the HTTPApplication object for my app., hence the redirect.config file was reloaded via IHTTPModule.Init.
No more ulcer. So, as Sunil Wettimuny famously said: I go now.