At 08:59 PM 11/20/2004, Yussef Alkhamrichi wrote: >>This brings up an interesting point. Yussef, try stopping the >>service, and start bin\apache.exe -X >> >>--- let's see if this is the parent process in the way. > >tested it running it in single-process mode (apache -X), it didn't help, but >the theory about multiple configuration loading sounds interesting, I'll keep >that in mind
Sure looks like the problem. Remember we bind mod_aspdotnet into memory (preventing it from unloading) by incrementing the refcount for the mapped module. So all the statics are preserved from pass 1 to 2 to 3, etc. Now look at asp_net_post_config() in mod_aspdotnet.cpp... you see we deliberately avoid restarting the HostFactory - it's almost impossible to cleanly remove and reinstantiate the Cor runtime as Apache wants us to do. But then drill down further, you will see we would call CreateHost for each pass through the config, and that means the preconfig check, then the live server statrup. But we have to decide what to do here. Either 1) the hosts aren't being torn down (and we need to), or 2) we need to avoid 'test creating' the hosts at initial startup. The gs (global server_rec) pointer is volatile upon subsequent config phases. It's possible if we call HostFactory->Destroy as a conf pool cleanup, we can wipe out all of these pre-tested hosts. Today, we only call Destroy with the asp_net_stop final destructor (when httpd is already shutting down, noted by the process->pool cleanup.) It's also possible we could walk the arrays of Host objects already created, and ignore any (harmful) duplicates, also saving ourselves from multiply-initializing the server. Actually I think that the array of servers in the HostFactory->hostSrv array all point to the same base server (IIUC). I'm checking that theory, if it's right this might be my preferred solution. Bill
