Keith Bostic <bostic@sleepycat.com> writes:
> > Anyhow, I'm CC'ing in Keith Bostic (Hi Keith, hope you don't mind),
> > hoping he can shed some light on this*.
> >
> > Keith: for the record, one of my repositories locked up one day.
> > First I tried to run 'dbrecover -v -h ${REPOS}/db'. This didn't
> > unlock my repos. Then I tried 'dbrecover -ve -h ${REPOS}/db' and
> > it did unlock my repos. Any ideas?
>
> The two calls to db_recover shouldn't make any difference with
> respect to unlocking your repository.
>
> We've been tracking this question as Support Request #6251.
>
> I think we need to first understand why the repository is locking
> up. How often does it happen? Can you make it happen at will?
I think both times happened when I called Subversion from Emacs, and
interrupted the operation.
> Generally, database environment hangups are caused by a thread
> of control exiting holding a Berkeley DB resource locked. This
> is a data structure mutex "lock" that I'm talking about, not a
> logical database read/write page "lock". The alternative is a
> thread of control exiting holding a logical lock, but that
> rarely causes a hang, it usually just means the application
> slowly grinds to a halt, it doesn't simply hang. Have you ruled
> out any possibility of a thread of control dying without having
> gracefully released a resource mutex?
The hangs are quite black-and-white: the next operation simply hangs
completely. It's not a grind-to-a-halt behavior at all. The
grind-to-a-halt behavior you're talking about comes from page locks
gradually accumulating across the database, right? So if the
application's page locking pattern is not randomly scattered across
the database (for example, I'll bet Subversion hits the filesystem's
root node pretty often), then you could get immediate hangs even from
page locks, right?
But this is speculation; I'll try to get a core dump.
> If so, the next debugging step is probably to force a core dump
> and sending me a stack trace of every thread of control in the
> database environment. That should enable us to speculate as to
> what might be the underlying cause.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 23 22:43:11 2002