Re: ldap_simple_bind blocks in Open Mode when the DS is in hang state

that is to be expected. unless you somehow manage to overflow related
OS buffers by continuously sending data i expect you should be able
to resume it cleanly. can you post full backtrace on the client side
showing which call is blocking exactly ?

denish patel wrote:
> One more thing, if I send a CONT signal to the OVD Process,
> then the bind call returns & the search works as expected.
> 
> On Mon, May 11, 2009 at 6:14 PM, denish patel <[email protected]>wrote:
> 
>> Here is the netstat output:
>> I am not using TLS / SSL connection.
>>
>>> netstat -apn | grep 1389
>> tcp        0      0 0.0.0.0:1389                0.0.0.0:*
>> LISTEN      17021/java
>> tcp       27      0 10.220.16.220:1389          10.220.16.220:36540
>> ESTABLISHED -
>> tcp        0      0 10.220.16.220:36540         10.220.16.220:1389
>> ESTABLISHED 20641/a.out
>>
>> The output of the program is as follows:
>> Init'ing
>> Inited
>> Setting OptionsSetting LDAP_X_OPT_CONNECT_TIMEOUT
>> LDAP_X_OPT_CONNECT_TIMEOUT Set
>> Getting LDAP_X_OPT_CONNECT_TIMEOUT
>> Value of LDAP_X_OPT_CONNECT_TIMEOUT : 10000
>> Setting LDAP_OPT_REFERRALS
>> Setting LDAP_OPT_REFERRALS
>> LDAP_OPT_REFERRALS Done
>> Setting LDAP_OPT_SIZELIMIT
>> LDAP_OPT_SIZELIMIT Done
>> Setting LDAP_OPT_TIMELIMIT
>> LDAP_OPT_TIMELIMIT
>> Getting LDAP_OPT_TIMELIMIT
>> Value of LDAP_OPT_TIMELIMIT : 10
>> Setting LDAP_OPT_NETWORK_TIMEOUT
>> Error setting the Timeout option : Unknown errorLDAP_OPT_NETWORK_TIMEOUT
>> Set
>> Getting LDAP_OPT_NETWORK_TIMEOUT
>> Error: ldap_get_option for NET_TIMEOUT: Unknown error
>> Value of LDAP_OPT_NETWORK_TIMEOUT : 0
>> Setting PRLDAP_OPT_IO_MAX_TIMEOUT
>> Error setting the PR timeout option : Unknown error
>> PRLDAP_OPT_IO_MAX_TIMEOUT Set
>> Setting LDAP_OPT_RECONNECT
>> LDAP_OPT_RECONNECT Set
>> Getting LDAP_OPT_RECONNECT
>> Value of LDAP_OPT_RECONNECT : 1
>> Getting PRLDAP_OPT_IO_MAX_TIMEOUT
>> Value of PRLDAP_OPT_IO_MAX_TIMEOUT : 0
>> Setting Protocol Version
>> Protocol Version Set
>> Binding to DS <- Blocked here.
>>
>>
>> Thanks,
>> Denish
>>
>>
>> On Mon, May 11, 2009 at 6:09 PM, Anton Bobrov <[email protected]>wrote:
>>
>>> do you use SSL/TLS on that connection? can you post netstat output
>>> showing that client connection state when you observe blocked bind?
>>>
>>> denish patel wrote:
>>>
>>>> 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
>>>>
>