From: "Bill Stoddard" <[EMAIL PROTECTED]> Sent: Thursday, November 15, 2001 7:22 AM
> > Apache 1.3.22 introduced a rather troubling bug in the listeners. > > > > Without introducing a huge burden of interlocking the individual > > sockets (a patch not worthy of the 1.3.23-dev tree), we can actually > > solve this since the Win32 accepts are all opened as non-exclusive. > > Therefore, if we drop the setup_listeners from the parent, entirely, > > and let the children open those listeners, the entire headache goes > > away. The old child continues to fulfill all remaining connections, > > and the new child fulfills all newly originated requests. > > > > Attached is a patch to do just that. Please review (Mr. Stoddard ;) > > > > Bill > > > > -1 at least until after we discuss this a bit more. > > With this patch, connections in the TCP listen queue will be dumped across a restart >(of > after hitting max requests per child). Opening the listeners in the parent and >allowing > the child processes to inherit the listeners keeps the listen queue intact across > restarts. Having two processes open the same port would introduce undefined >behaviour I > suspect (perhaps each will have their own listen queue). It sounds like we would need to transform the start_mutex to _not_ kill the original child until the new child had picked up all the listeners. This would not work, of course, if the original child segfaults :( > What exactly is the problem with POST? I'd like to investigate other solutions first. I need to look at the post options to ab or flood, to demonstrate. I suspect packets will be randomly delivered between the two processes. You can demonstrate (interactively) by quering server-status against 1.3.22, with keepalives on. As you restart, keep refreshing. The two servers will (alternating randomly) answer the status request, as indicated by uptime. With a post body, this would be poison. So yes, all new requests are rerouted properly by the 1.3.22 behavior, but all in-process requests are potentially corrupted. Bill
