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> 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] 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
