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. Also when you say that: --- the only thing you can do is to use async API and some timeout value on LDAP protocol/operations level eg if you are not getting a response to certain LDAP operation in 30 seconds bail out and return an error. ---
I tend to think that I am missing something here. Wouldn't LDAP_OPT_TIMELIMIT, LDAP_X_OPT_CONNECT_TIMEOUT be LDAP protocol level timeout values? 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. On Mon, May 11, 2009 at 5:18 PM, Anton Bobrov <[email protected]> wrote: > > denish, please keep this thread on the list. neither network or > connect timeout would apply in this case as i have explained in > my previous message. you can specify timeout for ldap_result() > call which is where it blocks in this case. again, this timeout > has nothing to do with network stack timeouts but simply a time > out for response on specific LDAP operation/s result/s. > > > denish patel wrote: > >> Thank you for you quick response. >> >> But that is what I am doing. I am using ldap_simple_bind (which is async), >> & specifying the timeout value. (LDAP_OPT_NETWORK_TIMEOUT, >> _CONNECT_TIMEOUT) >> Is there anything else that I need to be using? >> >> Thanks, >> Denish >> >> On Mon, May 11, 2009 at 4:01 PM, Anton Bobrov <[email protected]> >> wrote: >> >> you just pause server process execution with SIGSTOP but OS will keep >>> its files/sockets open and simply enqueue the data. connect and alike >>> will always succeed, recv and alike will block, on the client side so >>> none of the options you are setting will have any effect in this case. >>> the only thing you can do is to use async API and some timeout value >>> on LDAP protocol/operations level eg if you are not getting a response >>> to certain LDAP operation in 30 seconds bail out and return an error. >>> >>> >>> denish patel wrote: >>> >>> The behaviour I expect is that since the DS has been stopped & therefore >>>> would not be responding, >>>> the ldap_simple_bind() should return with a -1. >>>> >>>> Thanks, >>>> Denish >>>> >>>> On Mon, May 11, 2009 at 2:34 PM, Anton Bobrov <[email protected]> >>>> wrote: >>>> >>>> what behavior do you expect in this case ? why do you think it >>>> >>>>> should timeout when you send SIGSTOP to the server process ? >>>>> >>>>> >>>>> denish patel wrote: >>>>> >>>>> Hi All, >>>>> >>>>>> I have a simple LDAP Client that uses the Mozilla LDAP SDK. >>>>>> This client simulates how our software communicates with the Directory >>>>>> Server (OVD / Sun DS). >>>>>> >>>>>> Here are the steps that I follow: >>>>>> >>>>>> 1) ldap_init >>>>>> 2) ldap_set_option - set options - >>>>>> a) Version >>>>>> b) LDAP_X_OPT_CONNECT_TIMEOUT >>>>>> c) LDAP_OPT_REFERRALS to LDAP_OPT_ON >>>>>> d) LDAP_OPT_SIZELIMIT >>>>>> e) LDAP_OPT_TIMELIMIT >>>>>> f) LDAP_OPT_NETWORK_TIMEOUT (Unsuccessful even when the DS is up) >>>>>> (added >>>>>> later) >>>>>> g) PRLDAP_OPT_IO_MAX_TIMEOUT (Unsuccessful even when the DS is up) >>>>>> (added later) >>>>>> 3) ldap_simple_bind >>>>>> 4) query the Directory Server (DS) >>>>>> >>>>>> The client works perfectly when the DS is up. >>>>>> However when the DS is given a STOP signal, the Client gets blocked on >>>>>> the >>>>>> bind call. >>>>>> >>>>>> I have tried setting the TCP Timeout to a low value, but even that did >>>>>> not >>>>>> work. >>>>>> >>>>>> Is there anything more that I need to do? >>>>>> >>>>>> Thanks, >>>>>> Denish >>>>>> >>>>>> >>>>>> >> _______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
