Hi Anton,

Yes, it is multithreaded application. No, we are not using fibers.

Test case scenario:
In between Directory Server on machine1 and our application on machine
3, we have placed Proxy Workbench on machine 2. We have configured
Proxy Workbench such that, it will send only 1 byte of data from
Directory Server to our application in one minute.
In this scenario, we expected that, our application will failover to
the secondary Directory Server on machine 4. But, realized that, our
application is blocking bacause of LDAP C SDK 5.12 at the above
specified call stack.

When we debugged the LDAP C SDK code, we felt that, the time limit
specified in ldap_result call is getting applied only for poll
operation. And, recv call is getting blocked for the data from Primary
Directory Server on machine 1.

In wait4msg function [result.c file], poll is performed honoring the
timelimit. After to the poll, if there is any data to receive on
socket, read1msg function is getting called. Internally this is
calling BerRead function. Inside BerRead, bergetc function is getting
called in a while loop, until it receives expected length of message.

It would have been good, if before to every recv call, poll is done
with the remaining part of the allowed time limit and bail out if data
is not available with in the timelimit. Or else, non blocking socket
would have been used.

Ideally, ldap_result should behave in such a way that, it either
returns the data with in the specified time limit or bail out with
some status indicating TIMEOUT once the allowed time limit has been
elapsed.

Thanks,
Ramakrishna.

_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap

Reply via email to