On May 11, 5:03 pm, denish patel <[email protected]> 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. > 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 LDAPSDK. > >>>>>> 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
