Thanks Branko Cibej for your feedback.
I have checked we are not using any proxy or load balancer for our svn but
firewall in involved in our scenario. In case of firewall there is not
limit for data transfer for specific your over the network.You said there
is in between client and server which is Apache may be due to Apache
request time out this is happening ? I have searched on internet regarding
Apache request body parameter whose max limit is 2 GB means Apache can
carry max 2 GB request please confirm me if I am wrong may be due to this
limit svn commit is failing before 2 GB ? Should i consider Apache request
timeout parameter in httpd.conf ? Please suggest
Regards
Mohsin
On Sun, Sep 28, 2014 at 8:59 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 27.09.2014 09:24, Mohsin Abbas wrote:
>
> HI Philip Martin,
>
> Here is Tortoise SVN client and Apache error log portion :
>
> *Tortoise SVN Client Error :*
>
> Error: Commit failed (details follow):
> Error: PUT of
> Error:
> '/svn/test/!svn/wrk/6f036c59-c3a8-5947-91dd-bd0f1eeccd84/SomeFolder/brands.zip':
>
> Error: Could not send request body: An existing connection was forcibly
> closed by the
> Error: remote host.
> Error: (http://x.x.com)
>
> *Apache error.log portion :*
>
> [Sat Sep 27 11:21:44 2014] [error] [client x.x.x.x] mod_dav_svn
> close_stream: error closing write stream [500, #185004]
> [Sat Sep 27 11:21:44 2014] [error] [client x.x.x.x] Unexpected end of
> svndiff input [500, #185004]
>
>
> From the above, I'm almost certain that this is not Subversion's fault.
> Look at the error messages: the client thinks that the server closed the
> connection, but the server thinks that the client closed the connection; so
> the only reasonable explanation is that something *between* the client
> and server is in fact closing the connection.
>
> This could be a proxy, or a load balancer, or even a packet
> inspector/firewall (see http://markmail.org/message/tazxq3jexaopcdum for
> example) that's forcibly closing the connection.
>
> You'll have to talk to the server/site administrators to determine what's
> happening. There's not much anyone else can do without knowing how not just
> the server, but the whole data-centre are configured.
>
> -- Brane
>
>
Received on 2014-09-28 14:58:46 CEST