https://bz.apache.org/bugzilla/show_bug.cgi?id=61616
--- Comment #6 from Carsten Wolff <cars...@wolffcarsten.de> --- First of all, thanks for the very quick turnaround! Unfortunately, the patch doesn't fix the problem. Actually, I have played with similar approaches for changing proxy_connect_handler() before, like doing a poll() for POLLOUT on the backend upon every POLLIN event from the client before actually calling ap_proxy_transfer_between_connections(), or like prefering the direction "backend to client", when both sockets issue POLLIN events. But, no change to the poll() logic in mod_proxy_connect.c worked, because it's not there, where the poll() blocks. The whole situation can build up during one call of ap_proxy_transfer_between_connections(), when rsync daemon keeps sending long enough without reading, while rsync client is also sending. In that case apache will always block in apr/network_io/unix/sendrecv.c without a chance to return to mod_proxy again for another poll on the other socket. Is there a chance to parallelize the two data directions through threading or something? -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org
