> Apache 1.3.22 introduced a rather troubling bug in the listeners. > > Since we allow the child to start immediately, without waiting on > the prior child to finish, we have introduced a serious flaw. Both > processes are listening on the same socket, already primed to accept > connections. The client with an existing socket's data will be > randomly accepted by either process. This appears to be a serious > flaw, especially in POST data. > > This points out a larger simplification, perhaps not Win32 specific. > If we are shutting down a given child, we should be toggling keep_alive > off on the current requests, no? That definately drops the restart- > completion time. As I said, perhaps that's just a win32 anomily. > > 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). What exactly is the problem with POST? I'd like to investigate other solutions first. Bill
