Re: (ITS#5354) slapd repeatedly hangs and stops reponding

[orenl@cs.columbia.edu]

Howard Chu wrote:
> Oren Laadan wrote:
>>
>> Pierangelo Masarati wrote:
>>> hyc@symas.com wrote:
>>>> Oren Laadan wrote:
>>>>>> It shows enough; back-meta is hanging waiting for responses from 
>>>>>> some other
>>>>>> LDAP server. This is a pretty bad configuration; you should not 
>>>>>> use back-meta
>>>>>> (or back-ldap) to redirect queries back into the same slapd. You 
>>>>>> should use
>>>>>> back-relay instead.
>>>>> I'm not quite sure why having the server query itself is such a bad 
>>>>> idea.
>>>>> Can you please explain ?
>>>> Any request then occupies a minimum of two slapd threads - one for 
>>>> back-meta
>>>> itself, and one for the extra inbound query. If you misconfigure the 
>>>> meta URIs
>>>> then you get into an infinite loop, which consumes all of the 
>>>> available slapd
>>>> threads.
>>> Let me add that, moreover, any request is re-encoded as an LDAP request,
>>> sent to itself, re-decoded and re-processed by slapd.  Back-relay
>>> directly relies the original, decoded request to another database,
>>> within the same thread.  So it saves at least 3 resource-consuming 
>>> steps-
>>>
>>
>> Ok, I see the rational. So I guess my question is whether back-relay 
>> gives
>> the same functionality like ldap-meta (that is, merging the two 
>> databases,
>> the remote one and the local one) except better with respect to a local
>> database ?  and if so, then how would I set it up for this ?
>>
>> I looked at "subordinate" directive but I'm not sure it helps, since as
>> far as I could tell it can join two disjoint subtrees into seemingly one
>> big database. However, what I need is to add local (new) entries (not
>> only modify attributes) to an existing database.
> 
> This discussion has wandered off of potential bugs and into regular 
> software usage. You should pick this up again on the -software mailing 
> list. This ITS will be closed.

Well, the fact is that as far as I can tell the meta-URIs are not
mis-configured, the server works well for some random amount of time
and then reaches a lockup. True, the configuration isn't the optimal
in terms of performance. However, in the absence of text in the man
pages that prohibits doing so, the observed behavior is buggy.

In fact, there is at least one example in the archives of -software
that discusses a deployment of meta with "uri ldap://localhost/"; that
seems to have gone ok without too much criticism:
http://www.openldap.org/lists/openldap-software/200301/msg00112.html)

To that I'll add, that to the best of my knowledge and after reading
and re-reading the docs and the man-pages, I cannot find another way
to merge two databases (not distinct subtrees) such that a local db
adds entries to a remote db, but to use meta.

So: the config seems fine (see the original ticket), I need to use meta,
but it exhibits random lockups. Using a suboptimal solution is not a
bug. Random lockups are a symptom of a bug :(

(That said, I will ask on the -software list with regard to alternative
configurations, as you suggest).

Oren.