Re: Changing timeouts from a slapd module

[Michael Ströder <michael@stroeder.com>]

On 5/24/19 7:25 PM, dee heffem wrote:
> On 5/22/19 8:50 AM, Michael Ströder wrote:
> <snip>
>>
>> Each request is processed by a slapd worker-thread. But this means that
>> when setting
>>
>> threads n
>>
>> in your slapd.conf only max. n bind operations can wait for push
>> message. The next one will block
> 
> I'm running OpenLDAP 2.4.42 (Ubuntu package) on the  server which uses
> cn=config. zytrax shows the equivalent parameter being olcThreads which
> is 16 by default (I don't have the parameter set). Does this mean
> I should expect to get 16 "non-blocking" push requests running
> concurrently instead of only the one?

Glad you put non-blocking in quotes. ;-)

AFAIK the listener threads dispatch operations to worker threads which
call the appropriate backend and its configured overlays. Therefore in
the default case max. 16 bind operation can be processed in parallel.

>  Maybe I am misunderstanding -
> You mentioned earlier: "slapd worker thread is blocked for the whole
> processing time" so maybe this means the password overlay is not
> designed to run concurrently and this is all for naught?

No. It simply means that processing the LDAP operations is done
synchronously in worker thread.

>> BTW: Not sure about the capabilities of the 2FA service you're using.
>> Such a service might serialize all your calls or have some other type of
>> rate-limiting in place.
> 
> The vendor offers a "push test" utility which simply sends a user a
> push request to test the setup. I can indeed synchronously process
> pushes to two users at once (slapd out of the loop)

Really in a single OS process?

> The source code for the utility is available and the same push call
> they use is the one I use in the password overlay. The only difference
> is I had to recompile the API library statically for use with slapd.

This library could also serialize calls into the library with a lock.

Ciao, Michael.