You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@subversion.apache.org by "Daniel Sahlberg (Jira)" <ji...@apache.org> on 2021/08/10 21:15:00 UTC
[jira] [Comment Edited] (SVN-3264) Large directory checkouts fail,
connection forcibly closed
[ https://issues.apache.org/jira/browse/SVN-3264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396891#comment-17396891 ]
Daniel Sahlberg edited comment on SVN-3264 at 8/10/21, 9:14 PM:
----------------------------------------------------------------
There is a report in the TortoiseSVN user group at [https://groups.google.com/g/tortoisesvn/c/awNHQRlGzaI] where a merge is failing on the client side and giving almost the same errors on the server side:
Warning #1: "Provider encountered an error while streaming a REPORT response. [500, #0|#0]"
Warning #2: "A failure occurred while driving the update report editor [500, #730054|#730054]"
Warning #3: "The connection was closed by the remote host [500, #730054|#730054]"
The error numbers are different, but I believe that might be caused by the server being on Windows (it is a VisualSVN server, basically Apache httpd).
(No idea of this is related, but adding it here since the error messages looked a bit similar).
was (Author: dsahlberg):
There is a report in the TortoiseSVN user group at [https://groups.google.com/g/tortoisesvn/c/awNHQRlGzaI] where a merge is failing on the client side and giving almost the same errors on the server side:
Warning #1: "Provider encountered an error while streaming a REPORT response. [500, #0]"
Warning #2: "A failure occurred while driving the update report editor [500, #730054]"
Warning #3: "The connection was closed by the remote host [500, #730054]"
The error numbers are different, but I believe that might be caused by the server being on Windows (it is a VisualSVN server, basically Apache httpd).
> Large directory checkouts fail, connection forcibly closed
> ----------------------------------------------------------
>
> Key: SVN-3264
> URL: https://issues.apache.org/jira/browse/SVN-3264
> Project: Subversion
> Issue Type: Bug
> Components: mod_dav_svn
> Affects Versions: 1.5.x
> Environment: Windows 2000
> Reporter: Subversion Importer
> Priority: Major
> Fix For: unscheduled
>
>
> {noformat:nopanel=true}
> Large directory checkouts (with files hundreds of megabytes) fail on our
> relatively slow workstations. They function correctly on faster servers.
> The client side either reports:
> REPORT of '/source/svn/Common/!svn/vcc/default': Could not read response body:
> An existing connection was forcibly closed by the remote host.
> or:
> REPORT of '/source/svn/Common/!svn/vcc/default': Could not read chunk size: An
> existing connection was forcibly closed by the remote host.
> Here /source/svn/Common is the URL path to our repository.
> Apache reports:
> Provider encountered an error while streaming a REPORT response. [500, #0]
> A failure occurred while driving the update report editor [500, #190004]
> What seems to happen is:
> * We initiate a checkout
> * For each directory:
> - All files are transfered through the network to <DIR>\.svn\tmp\text-base\
> - Once all files have arrived, they are copied from
> <DIR>\.svn\tmp\text-base\* to <DIR>\
> The copy from <DIR>\.svn\tmp\text-base\ to <DIR>\ seems to take too long and we
> encounter some sort of timeout - at least, that is what seems to happen. The
> copy takes about five minutes, in one reproducible case.
> Server: Apache 2.2.8 or 2.2.9 with Subversion 1.5.0 or 1.5.1 on Linux RHEL ES 4
> update 5 (Apache and Subversion compiled from source)
> Client: Either TortoiseSVN 1.5.2, Build 13595 against Subversion 1.5.1, or
> Collabnet svn 1.5.1 (CLI) on Windows 2000.
> Things we have tried:
> * Setting the Apache Timeout to 3600
> * Disabling all authentication by removing the authz_svn and authn_bugzilla
> modules
> * Setting the Apache LimitXMLRequestBody to 0 (unlimited)
> * Setting the Apache DavMinTimeout to 3600
> A workaround is available: if the checkout fails, you can resume it by doing an
> update. But this is far from ideal.
> {noformat}
> Original issue reported by *frodol*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)