[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svn.collab.net repos failures.

From: Sander Striker <striker_at_apache.org>
Date: 2003-08-29 10:23:41 CEST

> From: cmpilato@localhost.localdomain
> [mailto:cmpilato@localhost.localdomain]On Behalf Of cmpilato@collab.net
> Sent: Friday, August 29, 2003 6:34 AM

> I'm not going to be hacking for the next week or so -- Ben or Karl
> will have to be your repository saviours during that time period.
> Until we figure out how to fix this problem ... um ... don't checkout
> anything. :-)

LOL... Hmm, actually, that isn't funny.
 
> (Seriously, I would really like someone to start spending some real time
> trying to diagnose and fix this problem -- in my opinion, this is a
> higher priority than any other currently known perf/scalability bug).

Justin and I are looking and trying things right now. Note that Justin
was also seeing Berkeley DB (4.1.25) going into an infinite loop.

Reverting the repository caching in mod_dav_svn/repos.c will let an
import* operation (that issues more than MaxKeepAliveRequests requests)
to complete, instead of going into the infinite loop.

Turning the caching back on and applying the 4.1.25 patch
(http://www.sleepycat.com/update/4.1.25/patch.4.1.25.html) will get the
import further along, but it does fail at some point.

Justin thinks his problem has something to do with a bug that is apparently
going to be fixed in 4.2.xx:
http://www.sleepycat.com/update/4.2.XX/if.4.2.XX.html
 Memory Pool Subsystem Changes
 2. Fix a bug where Berkeley DB could loop infinitely if the cache was sized
    so small that all of its pages were simultaneously pinned by the
    application. [#6681]

It will be hard to confirm, since 4.2.xx is "Scheduled for release in October 2003."

Back to the repos caching. I personally think it just papers over something.
We've had that code in 0.27 and didn't see the repos wedges we are seeing now.
Apparently a change between 0.27 and 0.28 is triggering the problem.

My gut tells me that either:
We are messing with the db state so it isn't reusable (in some cases?), or
we are recording some state inside repos->repos (which is a svn_repos_t)
allocated with a lifetime shorter than the one passed to svn_repos_open().
Note that repos->pool == request pool, whereas the pool passed to svn_repos_open()
is the connection pool (which gets recorded in repos->repos->fs->pool).

Investigating further...

Sander

*) Justin was doing an import first to try to look at the problem Mike reported;
   concurrent checkouts.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 29 10:24:36 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.