https://bz.apache.org/bugzilla/show_bug.cgi?id=61616
--- Comment #47 from Carsten Wolff <cars...@wolffcarsten.de> --- (In reply to Yann Ylavic from comment #46) > The pcap shows rsynd sending data at the (timeout/premature) end of > connection which is an error message (on the socket???). > Something's fishy there... Nothing fishy with that, AFAIK. rsync tries very hard to get error messages through to the user (behind the client). From a TCP perspective there's nothing wrong with sending data after receiving a FIN. The client may have "SHUT_WR" the socket and would still be able to receive that message and present it to the user. Of course the proxy has closed the socket at that point and thus sends an RST. I think this part is actually fine. (In reply to Yann Ylavic from comment #45) > By running the rsync loop indefinitely, it happens once in a while that > rsync and rsyncd stop communicating, but the proxy doesn't look at fault > here, it poll()s appropriately for reads on both sides but none seems to > want to send its remaining data. I can reproduce this and I see something in my capture, which is hard to see in yours, because you use all zeroes for the files contents (I use /dev/urandom). First of all, if I try with a much longer timeout than 10 seconds, then, after minutes, the transfer succeeds without error! During the "stall" I see : - in netstat: all involved socket buffers are empty - in trace8 log: proxy_connect is polling for POLLIN on both sockets Conclusion: All data sent by rsync server and client has been read by the proxy at that point. What I can see from my pcap: - The last data bytes the rsync server sends _before_ the stall are in packet 6717. - A tail chunk of these bytes is _not_ being sent to the client before the stall. - After minutes, the rsync client sends an empty message (\x00\x00\x00\x07 == len 0 MSG_DATA), which the proxy sends to the server, which causes the server to respond with the same empty message (maybe some sort of keepalive in rsync), which causes POLLIN on the proxy backend. Only after that, the proxy sends a data segment (packet 8252) to the client containing the remainder of packet 6717 plus the new message. Conclusion: Because all socket buffers are emtpy during the stall and proxy_connect polls for POLLIN, the delayed data must sit in the apache process during that time. Maybe under some circumstance c_o->data_in_output_filters being false is a lie (or simply not enough) and the data has been set aside somewhere without proxy_connect noticing? You can find the PCAP here: https://drive.google.com/file/d/1Rf4fI1MBIVZ8AF0XI49xDiPrryHgKaZz/view?usp=sharing -- 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
