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
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
> org.tmatesoft.svn.core.SVNException: svn: E175002: Connection reset
> svn: E175002: REPORT request failed on '//!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 :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 :0] Provider
> encountered an error while streaming a REPORT response. [400, #0]
> [dav:error] [pid 943370:tid 140318913550080] [client :0] Connection
> reset by peer [400, #104]
> [dav:error] [pid 943370:tid 140318863193856] [client :0] Provider
> encountered an error while streaming a REPORT response. [400, #0]
> [dav:error] [pid 943370:tid 140318863193856] [client :0] Broken pipe
> [400, #32]
> and
> [dav:error] [pid 935399:tid 140319082698496] [client :0] Provider
> encountered an error while streaming a REPORT response. [500, #0]
> [dav:error] [pid 935399:tid 140319082698496] (32)Broken pipe: [client
> :0] Error flushing brigade. [500, #175002]
> And
> [dav:error] [pid 935400:tid 140318141814528] [client :0] Provider
> encountered an error while streaming a REPORT response. [500, #0]
> [dav:error] [pid 935400:tid 140318141814528] [client :0] A failure
> occurred while driving the update report editor [500, #32]
> [dav:error] [pid 935400:tid 140318141814528] [client :0] Broken pipe
> [500, #32]
> And sometimes:
> [dav:error] [pid 21083:tid 140486543132416] [client :0] Provider
> encountered an error while streaming a REPORT response. [500, #0]
> [dav:error] [pid 21083:tid 140486543132416] [client :0] A failure
> occurred while driving the update report editor [500, #104]
> [dav:error] [pid 21083:tid 140486543132416] [client :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