Re: commit: ldap/servers/slapd connection.c

["Pierangelo Masarati" <ando@sys-net.it>]

>> back-ldbm in HEAD appears to be rather unstable at the moment, and I'm
>> afraid that my changes in connection management are part of the problem.
>> I notice that if I turn the debug level up high, test002 fails. Looking
>> at the slapd.1.log, it appears that Add operations are still in progress
>> when the final ldapsearch is done to retrieve the full database
>> contents.
>> This is really puzzling, it means that the ldapadd command exited
>> successfully already, but the operations it submitted hadn't completed
>> yet. With lower debug levels, the Adds complete quickly enough to finish
>> before the ldapsearch finishes. Otherwise, one to three entries from the
>> tail of the Add are missing from the search result.
>>
>> This also seems to be causing test008 to fail. Also in test008, there is
>> garbage text appearing in the LDAP error text fields. I don't know what
>> it's leftover from...
>>
>> The big problem here seems to be that back-ldbm calls send_ldap_result()
>> to tell the client its status before it actually finishes its internal
>> operations. So it can be in the middle of completing a cache update by
>> the time a new request arrives; this seems to explain what I'm seeing in
>> test002 at least.

would anticipating the call to cache_entry_commit() before sending result
be an option?

>
> Since LDBM is kind of deprecated in favor of BDB, etc, at what point does
> OL simply drop LDBM?  Would it in particular simplify things?

I wouldn't consider this an option yet.  We may need a fallback solution
in case any issue (even deployment-specific) occurs.

Ciao, p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497