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.