Re: NSPR I/O: Getting LDAP_PARAM_ERROR, instead of LDAP_TIMEOUT

i wonder if moving PRLDAP_OPT_IO_MAX_TIMEOUT upper [ as suggested
in a diff msg by Mark ] in that code  sample RamaKrishna posted
can fix LDAP_PARAM_ERROR ? if not we certainly need to track this
.

Mark Smith wrote:
> RamaKrishna Narla wrote:
>> Hi All,
>>
>> We are using Mozilla LDAP C SDK version 5.12. NSPR version 4.2.2. NSS
>> version 3.7.7.
>>
>> Using prldap_init instead of ldap_init, for the sake of NSPR I/O.
>> Setting PRLDAP_OPT_IO_MAX_TIMEOUT to 3 milli seconds, so that, our
>> application does not block even if Directory Server (DS) hangs or when
>> there is a delay in network traffic.
>>
>> We have simulated delay in network traffic by using ProxyWorkbench. We
>> have simulated DS hang by using faulty plugin to DS.
>> In both the above cases, LDAP synchronous calls (ldap_modify_ext_s and
>> ldap_delete_s) are not getting blocked, but returning the status as
>> LDAP_PARAM_ERROR, instead of LDAP_TIMEOUT.
>  > ...
> 
> Thank you for reporting this problem.  I did not run your sample, but 
> looking at the libldap and libprldap code it does not look like the 
> correct mapping is done between NSPR error codes and LDAP error codes in 
> the case when a timeout occurs during read or write operations.  Please 
> file a bug here:
> 
>    https://bugzilla.mozilla.org/enter_bug.cgi?product=Directory
> 
> Patches to fix this problem would be welcome.  I do not understand why 
> LDAP_PARAM_ERROR is returned.  You may be able to work around the 
> problem or reach a better understanding of it by checking the NSPR error 
> code after you get the LDAP_PARAM_ERROR result code.
> 
> -Mark Smith
>   Pearl Crescent
>   http://blog.pearlcrescent.com/
> _______________________________________________
> dev-tech-ldap mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-ldap