https://bz.apache.org/bugzilla/show_bug.cgi?id=61616
--- Comment #27 from Yann Ylavic <[email protected]> --- The logs from comment 21 and comment 26 look normal, no timeout triggered, proxy_connect_handler() seems to be waiting for sockets to be ready to do its job. (In reply to Carsten Wolff from comment #26) > I added this just at the end of the poll() loop: > ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r, > "@END: " > "[%s: POLLIN: %d POLLOUT: %d POLLHUP: %d data_in_filters: %d] " > "[%s: POLLIN: %d POLLOUT: %d POLLHUP: %d data_in_filters: %d]", > conns[0].name, > conns[0].pfd.reqevents & APR_POLLIN && 1, > conns[0].pfd.reqevents & APR_POLLOUT && 1, > conns[0].pfd.reqevents & APR_POLLHUP && 1, > conns[0].c->data_in_output_filters, > conns[1].name, > conns[1].pfd.reqevents & APR_POLLIN && 1, > conns[1].pfd.reqevents & APR_POLLOUT && 1, > conns[1].pfd.reqevents & APR_POLLHUP && 1, > conns[1].c->data_in_output_filters > ); > > > The whole long log looks like this sample: Events are fine here. > > Two things are peculiar: > - we no longer request APR_POLLHUP events. Is that intentional? POLLHUP is a returned event only (ignored when requested usually), though APR might maybe require it when pollset is implemented with select() (will loook at this), it shouldn't be the case on Linux hence for your testing... > - It seems like when ap_proxy_transfer_between_connections returns, > "data_in_output_filters" is always true on the outgoing connection and we're > always entering the "write wait" path. Yes, ap_proxy_transfer_between_connections() used to forward everything it reads until EAGAIN (non-blocking on read only), that's why the core output filter ended up blocking when the outgoing socket didn't follow the incoming rate. I changed this in attachment 35446 with a flag (AP_PROXY_TRANSFER_UNBUFFERED) to tell ap_proxy_transfer_between_connections() to stop when buffering happens in ouput too (i.e. data_in_output_filters), such that in this case mod_proxy_connect can use POLLOUT before trying again. -- 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]
