You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Troy Curtis Jr <tr...@gmail.com> on 2007/03/26 03:13:38 UTC
Timeout on commit (Connection Closed Unexpectedly)
Hi all,
At work several users have had their commit exit with the "Connection
Closed Unexpectedly" error message. Upon further investigation it
turns out that the commit makes it into the repository correctly, but
the working copy is left in such a screwed up state that they have to
do a fresh checkout to recover. (The working copy shows that the
commit failed and so does not update the version information for the
files commited, a 'svn up' causes conflicts galore). It also appears
that one particularly large text file (actually ridiculously large),
along with a generally large commit is common among the three case we
encountered (many other revs have gone through just fine).
Our repository is fairly large at ~2GB and 60k+ revisions.
Furthermore, our code tree is very complex with many many directories
at variable depths. We are using Subversion 1.4.1. The repository is
BDB back-end served off Subversion's own 'svnserve' server. I thought
I remembered something about the head revision re-write aspect of BDB
repos could cause timeouts on large commits but I couldn't find
anything on it.
Does anyone have any ideas? Would a transition to an Apache served
repository help?
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timeout on commit (Connection Closed Unexpectedly)
Posted by Troy Curtis Jr <tr...@gmail.com>.
On 3/28/07, David Parish <dp...@gmail.com> wrote:
> I had this problem with Apache as well. I fixed it by changing the
> following in httpd.conf (It was awhile ago so I may have forgotten
> something)
>
> KeepAlive on
> TimeOut 600
>
> -Dave
>
>
>
> On 3/28/07, Larry Martell <la...@gmail.com> wrote:
> > On 3/25/07, Troy Curtis Jr <tr...@gmail.com> wrote:
> > > Hi all,
> > > At work several users have had their commit exit with the "Connection
> > > Closed Unexpectedly" error message. Upon further investigation it
> > > turns out that the commit makes it into the repository correctly, but
> > > the working copy is left in such a screwed up state that they have to
> > > do a fresh checkout to recover. (The working copy shows that the
> > > commit failed and so does not update the version information for the
> > > files commited, a 'svn up' causes conflicts galore). It also appears
> > > that one particularly large text file (actually ridiculously large),
> > > along with a generally large commit is common among the three case we
> > > encountered (many other revs have gone through just fine).
> > >
> > > Our repository is fairly large at ~2GB and 60k+ revisions.
> > > Furthermore, our code tree is very complex with many many directories
> > > at variable depths. We are using Subversion 1.4.1. The repository is
> > > BDB back-end served off Subversion's own 'svnserve' server. I thought
> > > I remembered something about the head revision re-write aspect of BDB
> > > repos could cause timeouts on large commits but I couldn't find
> > > anything on it.
> > >
> > > Does anyone have any ideas? Would a transition to an Apache served
> > > repository help?
> >
> > I have seen this on repositories located on network drives accessed with
> > the file:/// method. I have never seen this on repos located on a server
> > accessed with https://. So I would say the answer to your question is yes.
> >
> > HTH,
> > -larry
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
PERFECT!! That is exactly the configurability that I thought would be
in place when using apache. It makes me feel much more confident now
in moving my users to the http method. I wanted to do it anyway
because of the ability to browse the repo from a web browser, and have
links off our internal wiki to the actual repository, etc. Now I can
be confident in waiting for the switch before investigating this issue
further.
Troy
--
"Beware of spyware. If you can, use the Firefox browser." - USA Today
Download now at http://getfirefox.com
Registered Linux User #354814 ( http://counter.li.org/)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timeout on commit (Connection Closed Unexpectedly)
Posted by David Parish <dp...@gmail.com>.
I had this problem with Apache as well. I fixed it by changing the
following in httpd.conf (It was awhile ago so I may have forgotten
something)
KeepAlive on
TimeOut 600
-Dave
On 3/28/07, Larry Martell <la...@gmail.com> wrote:
> On 3/25/07, Troy Curtis Jr <tr...@gmail.com> wrote:
> > Hi all,
> > At work several users have had their commit exit with the "Connection
> > Closed Unexpectedly" error message. Upon further investigation it
> > turns out that the commit makes it into the repository correctly, but
> > the working copy is left in such a screwed up state that they have to
> > do a fresh checkout to recover. (The working copy shows that the
> > commit failed and so does not update the version information for the
> > files commited, a 'svn up' causes conflicts galore). It also appears
> > that one particularly large text file (actually ridiculously large),
> > along with a generally large commit is common among the three case we
> > encountered (many other revs have gone through just fine).
> >
> > Our repository is fairly large at ~2GB and 60k+ revisions.
> > Furthermore, our code tree is very complex with many many directories
> > at variable depths. We are using Subversion 1.4.1. The repository is
> > BDB back-end served off Subversion's own 'svnserve' server. I thought
> > I remembered something about the head revision re-write aspect of BDB
> > repos could cause timeouts on large commits but I couldn't find
> > anything on it.
> >
> > Does anyone have any ideas? Would a transition to an Apache served
> > repository help?
>
> I have seen this on repositories located on network drives accessed with
> the file:/// method. I have never seen this on repos located on a server
> accessed with https://. So I would say the answer to your question is yes.
>
> HTH,
> -larry
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Timeout on commit (Connection Closed Unexpectedly)
Posted by Larry Martell <la...@gmail.com>.
On 3/25/07, Troy Curtis Jr <tr...@gmail.com> wrote:
> Hi all,
> At work several users have had their commit exit with the "Connection
> Closed Unexpectedly" error message. Upon further investigation it
> turns out that the commit makes it into the repository correctly, but
> the working copy is left in such a screwed up state that they have to
> do a fresh checkout to recover. (The working copy shows that the
> commit failed and so does not update the version information for the
> files commited, a 'svn up' causes conflicts galore). It also appears
> that one particularly large text file (actually ridiculously large),
> along with a generally large commit is common among the three case we
> encountered (many other revs have gone through just fine).
>
> Our repository is fairly large at ~2GB and 60k+ revisions.
> Furthermore, our code tree is very complex with many many directories
> at variable depths. We are using Subversion 1.4.1. The repository is
> BDB back-end served off Subversion's own 'svnserve' server. I thought
> I remembered something about the head revision re-write aspect of BDB
> repos could cause timeouts on large commits but I couldn't find
> anything on it.
>
> Does anyone have any ideas? Would a transition to an Apache served
> repository help?
I have seen this on repositories located on network drives accessed with
the file:/// method. I have never seen this on repos located on a server
accessed with https://. So I would say the answer to your question is yes.
HTH,
-larry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org