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
>>>
>>
>
_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap

Reply via email to