Colm MacCárthaigh <[EMAIL PROTECTED]> writes: > O.k., now that is interesting, another thing I've noticed is that when > the encoding is chunked, I can't replicate the problem. Presumably the > problem is related to how much data is trying to be sent down the > socket at once.
Well, note that Apache uses different socket APIs for dynamic content vs. static content, and chunking is only used for dynamic content. That should be related to the breakage. Also, the other poster mentioned that SSL works over IPv6 but non-SSL doesn't on one box. That also corresponds to the same difference in socket API usage. We can't use sendfile for any dynamic content. We can't use sendfile for encrypted static or encrypted dynamic content. So it really seems that sendfile is key to the issue. But I'm confused because you already disabled sendfile usage and that didn't bring some amount of happiness. Also, the path where we use sendfile is the path where we use TCP_CORK so how can there be a problem if we don't use sendfile()? double-checking where TCP_CORK is used: 1) APR_TCP_NOPUSH_FLAG is TCP_CORK on Linux 2) APR_TCP_NOPUSH socket option controls APR_TCP_NOPUSH_FLAG 3) apr_sendfile() for Linux is the only code that dorks with APR_TCP_NOPUSH (and thus TCP_CORK) So I still don't understand why disabling sendfile usage didn't avoid the problem, unless it isn't specific to TCP_CORK after all. Can you get an strace of an Apache child process attempting to serve a page in the failure case? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
