> 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