> > We're using Apache 1.3. The host definitely started off with 2 > servers - I've verified that in the server logs. Somewhere along the > way it loses one of them. I've got a cosign module running with lots > of debugging around that section of code - hopefully I can catch it > happening this time.
I think I've now got to the bottom of what's going on here, although I haven't yet coded a fix. It's to do with the way that Apache maintains and merges server configurations. When the cosign server list is produced (in set_cosign_host() ) it's attached to the module configuration structure that is currently in scope at that point. However, Apache may then merge this structure with others created lower down the hierarchy (by calling cosign_merge_cfg() ) before passing the configuration structure into the request handler. This means that there are potentially many copies of the pointer to the head of the server list. The problem arises when the server list gets shuffled - the pointer to the head of the list gets changed in the copy of the configuration structure that has been passed to the check_cookie routine, but not in any of the other copies. Critically, it doesn't get changed in the copy that was originally created, and from which all of the other configuration structures are being derived. So, you end up with a situation where elements of the list get lost. The reason that this isn't a bigger problem is that it relies on a particular set of situations *) The server configuration must have the cosign server list at a high enough level that merging occurs *) There must be replication delays between the cosign servers, such that one server in the list returns retry for a valid request. *) The server list must get shuffled *) The load on Apache is sufficiently low that a child (that has shuffled its list) handles multiple cosign authentications before being replaced The quick solution is to disable list shuffling. I think that the longer term solution is to add an additional level of indirection to the pointer between configuration structure and connection list, but was wondering if anyone else had any bright ideas? Cheers, Simon. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Cosign-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cosign-discuss
