Hi, Our setup: Subversion 1.10 on RHEL8 served by httpd 2.4 Reverse proxy httpd 2.4 on RHEL8
We're seeing one or more failures/day during SVN checkout/updates. There appear to be some variations on the error: These are the logs on the SVN (backend) server First type: [dav:error] Provider encountered an error while streaming a REPORT response. [500, #0] [dav:error] A failure occurred while driving the update report editor [500, #104] [dav:error] Error writing base64 data: Connection reset by peer [500, #104] Second type: [dav:error] Provider encountered an error while streaming a REPORT response. [500, #0] [dav:error] A failure occurred while driving the update report editor [500, #32] [dav:error] Error writing base64 data: Broken pipe [500, #32] Third: [dav:error] Provider encountered an error while streaming a REPORT response. [400, #0] [dav:error] Broken pipe [400, #32] Fourth: [dav:error] Provider encountered an error while streaming a REPORT response. [400, #0] [dav:error] Connection reset by peer [400, #104] Clients are both TortoiseSVN on Windows and Jenkins SVNkit on Windows and Linux. Am I correct to assume that it is the client (or something between the client and the proxy server) that is breaking the connection? Or is this a problem on either of the apache servers? In the error_log of the proxy server I see errors like: [Thu Jan 14 06:42:01.647633 2021] [proxy_http:error] [pid 17204:tid 140412413015808] (104)Connection reset by peer: [client 192.168.x.y:38940] AH01102: error reading status line from remote server <backend SVN server>:443 For this error the following SO post (https://stackoverflow.com/a/64365796/1313616) suggests to add ` SetEnv proxy-initial-not-pooled 1` but https://httpd.apache.org/docs/2.4/mod/mod_proxy_http.html warns that this may downgrade performance. But the timings of these errors do not match the dav:error error messages. Clocks on both servers are synchronized via NTP. How can I fix/troubleshoot this further? I cannot reliably reproduce this on the dev server using a single large checkout. I have found that when a lot of checkouts are triggered simultaneously the error happened. Whether that was because of the high load or simply because more checkouts increase the chance of running into the problem is not clear to me. Thanks in advance Bram
