https://bz.apache.org/bugzilla/show_bug.cgi?id=56984
--- Comment #11 from [email protected] --- Hello Yann, Thanks for your clear story about the design principles. I can see that coalescing writes to the client means more performance. I was also missing the point about idempotent requests. The browser/client should not resend possible non-idempotent requests as soon as they have left the client even if it doesn't get a reply from the server. I still think though that there are some concerns about this when you have requests with a long runtime, high pool usage and very small ack-like response. It could take several requests before any output gets sent back and memory gets cleared. Also apache modules that didn't get updated to take this into account can misbehave as is now painfully clear. Not only can they have issues with pool cleanups not having run, but also with reentry of handlers that are also registered for output filters and respond to an EOS bucket of a previous request while processing a follow-on request. Most of the time I am just the custodian of a webserver and am most concerned with it functioning reliable and not having the highest possible performance. So I guess what I should be asking is, can we make it a feature request to have the option of configging Apache 2.4 to do a flush after each client request? Thanks. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
