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