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
