Anton, Actually what I tried to mention was that my LDAP Client blocks up on the ldap_simple_bind call. So, when the DS has been stopped, I do not see the LDAP Client coming out / moving ahead of the bind call.
So I do not even get to make the ldap_result call when the DS has been stopped. On Mon, May 11, 2009 at 5:59 PM, Anton Bobrov <[email protected]> wrote: > > denish patel wrote: > >> Apologies for that Anton. >> I seem to get the point here. >> Just to clarify, the LDAP Client is blocking on the ldap_simple_bind() >> call & not the ldap_result() call. >> > > exactly the opposite. > > I tend to think that I am missing something here. >> Wouldn't LDAP_OPT_TIMELIMIT, LDAP_X_OPT_CONNECT_TIMEOUT >> > > TIMELIMIT is timeout enforced by the server for search operations. it > has nothing to do with this. in any case it wont be applicable here > because your server is paused by SIGSTOP anyway. CONNECT_TIMEOUT will > never apply in this case because even with the server paused by STOP > client connect() call will succeed thus no connect timeout will occur. > > If the expected behaviour here is the same as you specified in your >> earlier >> response, then the only solution I can think as of now is the use of >> alarm() >> call / another thread monitoring the bind call. >> > > all you have to do is to specify timeout argument for ldap_result(). > _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
