Re: Changing timeouts from a slapd module

[dee heffem <dheffem@gmail.com>]

On 5/24/19 12:58 PM, Michael Ströder wrote:

<snip>

> 
> 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?

Perhaps I misrepresented. This was done in two different terminal
processes.


>> 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.


I was busy with a few other projects this week but just came back to
this. I was going through some code and this caught my eye:

   static ldap_pvt_thread_mutex_t my_mutex;
   ...
   ldap_pvt_thread_mutex_lock (...);
   ...
   ldap_pvt_thread_mutex_unlock (...);


in my password overlay. I used some of the contrib overlays to
develop with and the radius.c overlay used this. I guessed it
best to implement the same since I am also using an external API.

I don't have time today to experiment but this may be where the
blocking is coming from.  Would you know what the intention
of ldap_pvt_thread_mutex_t is from the standpoint of the
password overlay?

Thank you