You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Alexey Neyman <st...@att.net> on 2013/06/29 00:36:38 UTC
Re: Merge error with SVN 1.8.0
[copying dev@ because I found what the issue is]
Hi,
Did some further investigation and it turns out that SVN1.8 client creates more
connections to the server when performing 'svn merge' - exceeding the xinetd's
default number of connections per source (10) and indeed, closing the connection on
an unsuspecting client. After increasing the number of connections per source to
unlimited, the merge went through.
Here are some statistics:
SVN 1.7, merge --reintegrate
13 connections total, 5 concurrent connections maximum
SVN 1.8, merge
18 connections total, 11 concurrent connections maximum
SVN 1.8, merge --reintegrate
5 connections total, 3 concurrent connections maximum
So, it looks like the new code for automatic detection of "reintegration merges" in 1.8
spawns a bunch of additional connections. So, the question is - what is the maximum
number of connections that a client can create to a server? Does it depend on the size
of the change? Size of the svn:mergeinfo?
I am not comfortable leaving the server configuration at "unlimited", seeing that
xinetd limit is a safety net against runaway client bringing down the server.
Regards,
Alexey.
On Sunday, June 23, 2013 12:56:27 PM Alexey Neyman wrote:
Hi,
I've tried upgrading the client to SVN 1.8, and now see some strange merge errors
while reintegrating the branch. According to
http://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate
the --reintegrate option is now deprecated, its use is discouraged and SVN should be
able to figure that out automatically. However, when I tried a plain "svn merge", it
gave me the following error:
[aneyman@build2 trunk]$ svn merge ^/MERGE-PATH
svn: E210002: Unable to connect to a repository at URL 'svn://MERGE-URL'
svn: E210002: Network connection closed unexpectedly
Strangely, 'svn merge --reintegrate' worked fine.
We are running 1.6.11 on the server (stock RedHat RPM, "1.6.11-2.el6_1.4" version). I
installed SVN 1.8.0 RPM from WanDisco ("1.8.0-1") on the client.
Any clues/suggestions as to how to debug this further?
Regards,
Alexey.
Re: Merge error with SVN 1.8.0
Posted by Alexey Neyman <st...@att.net>.
On Saturday, June 29, 2013 01:18:16 PM Stefan Sperling wrote:
> On Fri, Jun 28, 2013 at 03:36:38PM -0700, Alexey Neyman wrote:
> > [copying dev@ because I found what the issue is]
> >
> > Hi,
> >
> > Did some further investigation and it turns out that SVN1.8 client creates
> > more connections to the server when performing 'svn merge' - exceeding
> > the xinetd's default number of connections per source (10) and indeed,
> > closing the connection on an unsuspecting client. After increasing the
> > number of connections per source to unlimited, the merge went through.
> >
> > Here are some statistics:
> >
> > SVN 1.7, merge --reintegrate
> > 13 connections total, 5 concurrent connections maximum
> >
> > SVN 1.8, merge
> > 18 connections total, 11 concurrent connections maximum
> >
> > SVN 1.8, merge --reintegrate
> > 5 connections total, 3 concurrent connections maximum
> >
> > So, it looks like the new code for automatic detection of "reintegration
> > merges" in 1.8 spawns a bunch of additional connections. So, the question
> > is - what is the maximum number of connections that a client can create
> > to a server? Does it depend on the size of the change? Size of the
> > svn:mergeinfo?
> >
> > I am not comfortable leaving the server configuration at "unlimited",
> > seeing that xinetd limit is a safety net against runaway client bringing
> > down the server.
> I'm not entirely sure how to estimate the largest number
> of connections made by 'svn merge'.
>
> Note that the number of connections also depends on the amount of
> svn:externals involved in checkouts and updates. One new connection
> is opened for each external.
>
> You might be interested in Ivan's RA session reuse patch:
> http://svn.haxx.se/dev/archive-2013-06/0292.shtml
> http://subversion.tigris.org/issues/show_bug.cgi?id=3763
> This will probably be in 1.9, so it won't help you now. But I still
> thought it was worth mentioning since it will address your problem
> in the long term.
Sorry for a late response. The checked out WC I did a merge in did not have any
externals, but it had 8 svn:mergeinfo entries, if it matters.
I think at the very least this issue needs to be reflected in the "SVN book". Right now,
the section "svnserve via xinetd" does not mention it, nor does the example
configuration specify an unlimited number of connections per source. Given that
xinentd's default is 10 connections per source IP, it is fairly easy to go over that limit.
As to session reuse: am I right that it is going to avoid closing connections and reuse
it instead of opening a new one? In that case, it does not solve an issue with
concurrent connections (as they're still active, they can't be reused).
Regards,
Alexey.
Re: Merge error with SVN 1.8.0
Posted by Alexey Neyman <st...@att.net>.
On Saturday, June 29, 2013 01:18:16 PM Stefan Sperling wrote:
> On Fri, Jun 28, 2013 at 03:36:38PM -0700, Alexey Neyman wrote:
> > [copying dev@ because I found what the issue is]
> >
> > Hi,
> >
> > Did some further investigation and it turns out that SVN1.8 client creates
> > more connections to the server when performing 'svn merge' - exceeding
> > the xinetd's default number of connections per source (10) and indeed,
> > closing the connection on an unsuspecting client. After increasing the
> > number of connections per source to unlimited, the merge went through.
> >
> > Here are some statistics:
> >
> > SVN 1.7, merge --reintegrate
> > 13 connections total, 5 concurrent connections maximum
> >
> > SVN 1.8, merge
> > 18 connections total, 11 concurrent connections maximum
> >
> > SVN 1.8, merge --reintegrate
> > 5 connections total, 3 concurrent connections maximum
> >
> > So, it looks like the new code for automatic detection of "reintegration
> > merges" in 1.8 spawns a bunch of additional connections. So, the question
> > is - what is the maximum number of connections that a client can create
> > to a server? Does it depend on the size of the change? Size of the
> > svn:mergeinfo?
> >
> > I am not comfortable leaving the server configuration at "unlimited",
> > seeing that xinetd limit is a safety net against runaway client bringing
> > down the server.
> I'm not entirely sure how to estimate the largest number
> of connections made by 'svn merge'.
>
> Note that the number of connections also depends on the amount of
> svn:externals involved in checkouts and updates. One new connection
> is opened for each external.
>
> You might be interested in Ivan's RA session reuse patch:
> http://svn.haxx.se/dev/archive-2013-06/0292.shtml
> http://subversion.tigris.org/issues/show_bug.cgi?id=3763
> This will probably be in 1.9, so it won't help you now. But I still
> thought it was worth mentioning since it will address your problem
> in the long term.
Sorry for a late response. The checked out WC I did a merge in did not have any
externals, but it had 8 svn:mergeinfo entries, if it matters.
I think at the very least this issue needs to be reflected in the "SVN book". Right now,
the section "svnserve via xinetd" does not mention it, nor does the example
configuration specify an unlimited number of connections per source. Given that
xinentd's default is 10 connections per source IP, it is fairly easy to go over that limit.
As to session reuse: am I right that it is going to avoid closing connections and reuse
it instead of opening a new one? In that case, it does not solve an issue with
concurrent connections (as they're still active, they can't be reused).
Regards,
Alexey.
Re: Merge error with SVN 1.8.0
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jun 28, 2013 at 03:36:38PM -0700, Alexey Neyman wrote:
> [copying dev@ because I found what the issue is]
>
> Hi,
>
> Did some further investigation and it turns out that SVN1.8 client creates more
> connections to the server when performing 'svn merge' - exceeding the xinetd's
> default number of connections per source (10) and indeed, closing the connection on
> an unsuspecting client. After increasing the number of connections per source to
> unlimited, the merge went through.
>
> Here are some statistics:
>
> SVN 1.7, merge --reintegrate
> 13 connections total, 5 concurrent connections maximum
>
> SVN 1.8, merge
> 18 connections total, 11 concurrent connections maximum
>
> SVN 1.8, merge --reintegrate
> 5 connections total, 3 concurrent connections maximum
>
> So, it looks like the new code for automatic detection of "reintegration merges" in 1.8
> spawns a bunch of additional connections. So, the question is - what is the maximum
> number of connections that a client can create to a server? Does it depend on the size
> of the change? Size of the svn:mergeinfo?
>
> I am not comfortable leaving the server configuration at "unlimited", seeing that
> xinetd limit is a safety net against runaway client bringing down the server.
I'm not entirely sure how to estimate the largest number
of connections made by 'svn merge'.
Note that the number of connections also depends on the amount of
svn:externals involved in checkouts and updates. One new connection
is opened for each external.
You might be interested in Ivan's RA session reuse patch:
http://svn.haxx.se/dev/archive-2013-06/0292.shtml
http://subversion.tigris.org/issues/show_bug.cgi?id=3763
This will probably be in 1.9, so it won't help you now. But I still
thought it was worth mentioning since it will address your problem
in the long term.
Re: Merge error with SVN 1.8.0
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jun 28, 2013 at 03:36:38PM -0700, Alexey Neyman wrote:
> [copying dev@ because I found what the issue is]
>
> Hi,
>
> Did some further investigation and it turns out that SVN1.8 client creates more
> connections to the server when performing 'svn merge' - exceeding the xinetd's
> default number of connections per source (10) and indeed, closing the connection on
> an unsuspecting client. After increasing the number of connections per source to
> unlimited, the merge went through.
>
> Here are some statistics:
>
> SVN 1.7, merge --reintegrate
> 13 connections total, 5 concurrent connections maximum
>
> SVN 1.8, merge
> 18 connections total, 11 concurrent connections maximum
>
> SVN 1.8, merge --reintegrate
> 5 connections total, 3 concurrent connections maximum
>
> So, it looks like the new code for automatic detection of "reintegration merges" in 1.8
> spawns a bunch of additional connections. So, the question is - what is the maximum
> number of connections that a client can create to a server? Does it depend on the size
> of the change? Size of the svn:mergeinfo?
>
> I am not comfortable leaving the server configuration at "unlimited", seeing that
> xinetd limit is a safety net against runaway client bringing down the server.
I'm not entirely sure how to estimate the largest number
of connections made by 'svn merge'.
Note that the number of connections also depends on the amount of
svn:externals involved in checkouts and updates. One new connection
is opened for each external.
You might be interested in Ivan's RA session reuse patch:
http://svn.haxx.se/dev/archive-2013-06/0292.shtml
http://subversion.tigris.org/issues/show_bug.cgi?id=3763
This will probably be in 1.9, so it won't help you now. But I still
thought it was worth mentioning since it will address your problem
in the long term.