On Wednesday 28 November 2001 02:18 pm, Cliff Woolley wrote: The lingering close one is correct. I would bet that the other is a bug, The other is happening because of pipelining. Basically, you have gotten an EOS bucket, but the core might have squirelled away the data to be sent with the next response over this connection. If the check_pipeline_flush doesn't find another request, it has to flush the core_output_filter to get the data out. If you look at the core_output_filter, you will see that an EOS bucket allows the data to be saved, but FLUSH buckets are taken to mean write that data no matter what.
Ryan > Can someone explain to me why in the following gdb trace, even after the > entire request has been sent down the line EOS and all, there are two more > calls down the stack with FLUSH buckets? This is the worker MPM (dunno if > that matters) and an HTTP/0.9 GET request of an 8KB parsed file. One of > them seems to be lingering-close related, but I'm not sure about the other > one. They might both be totally correct, I just wasn't expecting to see > them happen. > ______________________________________________________________ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --------------------------------------------------------------
