[Date Prev][Date Next]
Re: Overlays and OpenLDAP multi-threading model
>> Now I understand a bit more of your question. OpenLDAP does not work as
>> presume you imagined. There is one thread that listens for requests.
>> soon as a request is received, an operation structure is created, and
>> queued for execution. As soon as one thread is available from a thread
>> pool, the first operation in the queue is executed. So threads *do not*
>> accept connections (a connection is a persistent channel between the
>> client and the server; a connection is not related to a thread). A
>> specific thread accepts requests (a request is mapped onto an
>> and each operation is executed by a different thread.
> Thanks for your explanation. But, is this operation structure also
> points (or stores)
> connection related data like the binding DN and it's credentials
> (password) ? If
> so, do you can point me in which structure member it is stored ? The
> has to have those informations...
The Operaton structure points to the Connection structure (op->o_conn,
which is actually a macro that expands to op->o_hdr->oh_conn); it also
contains copies of data that could be modified. For example, the DN the
connection is bound as is in op->o_dn (pretty) and op->o_ndn (normalized).
It is a copy, because the operation could modify it (e.g. via the proxied
authorization control). The original value is in op->o_conn->c_ndn. Of
course credentials are not stored; actually, slapd should have no notion
of how the client bound after the bind succeeds, except for what type of
mechanism was used, and the related ssf.
>> If your overlay takes a lot of time, in principle it will only affect
>> operation. If the client is performing multiple operations
>> only that operation will be delayed. Of course, if all operations use
>> your overlay, and all operations of your overlay take a lot of time, at
>> some point all the threads of the pool will be busy. Further requests
>> will be accepted by the listener thread, but they will be queued until
>> thread of the pool is available.
> Great! So the overall performance of OpenLDAP won't be compromised, once
> the overlay will only act over modifications operations of one
> attribute (userPassword).
Your overlay can access the password during a simple bind operation. It
is in op->orb_cred.