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.