Re: Overlays and OpenLDAP multi-threading model

[Lucas Brasilino <lucas.brasilino@gmail.com>]

Hi

> Now I understand a bit more of your question.  OpenLDAP does not work as I
> presume you imagined.  There is one thread that listens for requests.  As
> 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 operation),
> 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 overlay
has to have those informations...

> If your overlay takes a lot of time, in principle it will only affect its
> operation.  If the client is performing multiple operations concurrently,
> 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 one
> 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).

Regards
Lucas Brasilino