Re: slapd hangs at 100% cpu in sched_yield (ITS#2030)

[steven.wilton@team.eftel.com]

How about adding the following lines to the patch you have applied to cvs?  If the lock is rejected for the given reason, there is nothing major wrong with the database, but we should retry. The client program does not know that the ldap server is only having a temporary error getting the data (as opposed to if the lock is rejected due to something like a corrupt database, where we should send an error back to the client).

+retry:
                rc = LOCK_ID ( bdb->bi_dbenv, &locker );
                switch(rc) {
                case 0:
                        break;
+               case DB_LOCK_NOTGRANTED:
+                       ldap_pvt_thread_yield();
+                       goto retry;
                default:
                        return LDAP_OTHER;
                }


We use ldap to authenticate users, and if one of the ldap client programs detects an error, unusual things will happen on the system (some requests will work, while a random number of connections will fail for no good reason).

Steven

On Tue, 20 Aug 2002 09:48:11 Kurt D. Zeilenga wrote:
>I agree that the return result of LOCK_ID() should be checked.
>I've added code which causes an LDAP_OTHER error if LOCK_ID()
>fails, which in a quick check of DB4 code, is consistent with
>possible error conditions.
>Kurt