On Tue, Aug 28, 2001 at 09:44:43PM -0700, Greg Stein wrote:
>...
> Given that, I began running the mass-commit script again. We still have the
> two remaining problems:
>
> * WC locks bugging up the commits
> * the DB_INCOMPLETE thang
>
> The latter is actually posing a significant problem now. I kept running out
>...
> Oops! What I found instead was a number of file descriptors pointing to the
> DB files. These leaked file descriptors also referenced the log files which
> I was trying to delete... Of course, the system still referred to them, so
> they were still using disk space.
>...
> I am now suspecting the leaked descriptors are because we bail out during
> the DB->close routines. When one of them returns DB_INCOMPLETE, I think the
> logic just bails out (gotta go look).
>
> Regardless of what is happening, we have to get those descriptors closed. We
> can't be leaking descriptors on the server like that. So... that is my
> current task.
I just added a "sleep 1" after each commit in the mass-commit script. This
prevented all occurances of the DB_INCOMPLETE error. Further, it prevented
the descriptor leak.
[ basically, it gave a pause to let Apache clean up the previous request
before processing the next commit request ]
Thus: simultaneous access is causing DB_INCOMPLETE (not a surprise, given
the Berkeley docs), the DB_INCOMPLETE is messing up our close, and we are
leaking.
While I'm going to look into this tomorrow, I'll note that it is not really
a showstopper for M3. The database is not damaged, content is fine, and
further processing is fine. While we may leak descriptors and hold open
logs, it is very easy to have Apache recycle the processes to clean these
up. I *do* expect to get the close mostly fixed up, but I also want to
ensure that people have it in the proper perspective.
More and varied testing is, of course, still called for before we shift to
self-hosting. At this point, we do not have any known showstoppers. That
means we have 5 left ;-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:37 2006