On 5/24/19 7:25 PM, dee heffem wrote:
On 5/22/19 8:50 AM, Michael Ströder wrote:
> 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
> 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.