> From: Greg Stein <gstein_at_gmail.com>
> On Wed, Jul 20, 2011 at 09:23, <kmradke_at_rockwellcollins.com> wrote:
> > Greg Stein <gstein_at_gmail.com> wrote on 07/19/2011 06:53:12 PM:
> >> On Tue, Jul 19, 2011 at 10:41, C. Michael Pilato
> >> wrote:
> >> >...
> >> > release-readiness? What about ra_serf's "default-ness" -- is it
> >> > appropriate state based on that library's readiness at this moment?
> >> The only pending serf issue is my testing of a fix to memory blowup
> >> ra_serf when somebody checks out a repository root (ie. 10's of
> >> thousands of files across trunk, tags, and branches). Personally, I
> >> think it is a bug that could be fixed in 1.7.1, but I'm shooting to
> >> get the code tested for a 1.7.0 release. It is currently disabled on
> >> trunk and 1.7.x, but a simple two-line fix enables it.
> > I've seen revisions where millions (yes, I said millions) of files
> > changed at one time, so I feel ra_serf needs to be able to handle
> > 10's of millions of files in trunk alone during an update without
> > needing TBs of memory...
> > (I'm not saying I would recommend using Subversion in this way, just
> > that I have seen older versions abused in amazing ways...)
> Not saying it shouldn't be fixed... just saying that I'm unsure that
> it is a *release-blocker*. Or more precisely, that it is an issue that
> would cause serf to no longer be the default.
I guess I would consider a large increase in memory use a release
blocker/enough to make serf no longer the default. In my experience,
10's of thousands of files is no longer a "large" test case.
Somewhat off-topic, but there was also previous concern that
the multiple connections that serf uses might overly stress some
larger servers. Do we have any idea how many additional connections
a typical server would see? For example, if I see 1000 concurrent
connections to a server with neon, will I need to support 10000 shorter
connections with serf? (The 10x I chose is purely arbitrary and
not based upon any knowledge of the actual differences...)
> In any case, I've got all the code written, and a test plan and code
> for verification. It should make 1.7.0 without much problem (assuming
> that I haven't horrendously messed up my approach).
Good to hear we already know the potential solution!
Received on 2011-07-20 19:02:39 CEST