Hi Pavel, Yes, I have added that option but the problem persists. Note that we also have the problem using the TortoiseSVN client.
Regards Bram From: Pavel Lyalyakin <pavel.lyalya...@visualsvn.com> Sent: Monday, 27 September 2021 15:38 To: Bram Mertens <bram.mert...@anubex.com> Cc: users@subversion.apache.org Subject: Re: How to troubleshoot/resolve "connection was forcibly closed by the remote host" Hello Bram, Did you enable Spooling in SVNKit? See https://stackoverflow.com/a/57789602/761095 On Mon, Sep 27, 2021 at 2:15 PM Bram Mertens <bram.mert...@anubex.com<mailto:bram.mert...@anubex.com>> wrote: Hi, Our users (mostly on Windows using TortoiseSVN) and our Jenkins CI builds report errors during checkout and commit of our SVN repositories a couple of times a day. In TortoiseSVN the error message is usually "Error running context: An existing connection was forcibly closed by the remote host.". In Jenkins the stack trace usually shows: ERROR: Failed to check out <URL> org.tmatesoft.svn.core.SVNException: svn: E175002: Connection reset svn: E175002: REPORT request failed on '/<repo>/!svn/vcc/default' ... Caused by: javax.net.ssl.SSLException: Connection reset The problem occurs more frequently since we migrated the SVN repositories from a Debian Linux 8 server with subversion 1.9.5-1+deb9u1 and apache 2.4.25-3+deb9u3 to a RHEL 8 server with subversion-1.10.2-4.module+el8.3.0+9886+ac338b6d and apache 2.4.37-30.module+el8.3.0+7001+0766b9e7. Another main difference is that the old Debian server was located inside our DMZ. The new server is in our LAN and an apache reverse proxy server (also RHEL8 with apache 2.4.37-30.module+el8.3.0+7001+0766b9e7) is in the DMZ proxying requests to the SVN server. In the apache error_log of the proxy server we see occasionally (far fewer than the amount of failures) [proxy_http:error] [pid 716257:tid 140295500982016] (103)Software caused connection abort: [client 192.168.14.209:56678<http://192.168.14.209:56678>] AH01102: error reading status line from remote server <hostname>:443 In the apache error_log of the SVN server we see other errors but also less than the amount of failures reported by users: [dav:error] [pid 943370:tid 140318913550080] [client <IP>:0] Provider encountered an error while streaming a REPORT response. [400, #0] [dav:error] [pid 943370:tid 140318913550080] [client <IP>:0] Connection reset by peer [400, #104] [dav:error] [pid 943370:tid 140318863193856] [client <IP>:0] Provider encountered an error while streaming a REPORT response. [400, #0] [dav:error] [pid 943370:tid 140318863193856] [client <IP>:0] Broken pipe [400, #32] and [dav:error] [pid 935399:tid 140319082698496] [client <IP>:0] Provider encountered an error while streaming a REPORT response. [500, #0] [dav:error] [pid 935399:tid 140319082698496] (32)Broken pipe: [client <IP>:0] Error flushing brigade. [500, #175002] And [dav:error] [pid 935400:tid 140318141814528] [client <IP>:0] Provider encountered an error while streaming a REPORT response. [500, #0] [dav:error] [pid 935400:tid 140318141814528] [client <IP>:0] A failure occurred while driving the update report editor [500, #32] [dav:error] [pid 935400:tid 140318141814528] [client <IP>:0] Broken pipe [500, #32] And sometimes: [dav:error] [pid 21083:tid 140486543132416] [client <IP>:0] Provider encountered an error while streaming a REPORT response. [500, #0] [dav:error] [pid 21083:tid 140486543132416] [client <IP>:0] A failure occurred while driving the update report editor [500, #104] [dav:error] [pid 21083:tid 140486543132416] [client <IP>:0] Error writing base64 data: Connection reset by peer [500, #104] We see the problem mostly with some of our large repositories although we have also seen it with much smaller repos. I *suspect* that the larger amount of queries needed to checkout a larger repository just means that it is statistically more likely to experience this issue. We also appear to see the problem more often on Windows clients than on Linux but the problem does occur on both OS's. Our Windows clients (servers and laptops) are considerably slower to check out the same repository. Part of this is probably caused by Anti virus software I have already increased the apache timeouts. I have set up a proxy server in our LAN and I'm running some tests to see if I can reproduce the problem bypassing the Firewall but because there is no fixed procedure to reproduce the problem I cannot yet draw conclusions from this. How can I find out what is causing these connection issues? Thanks in advance Bram -- With best regards, Pavel Lyalyakin VisualSVN Team
