can you post a proper backtrace showing libldap calls as well ?
attach to your app with debugger of your choice and obtain full
backtrace on thread blocked in bind.
denish patel wrote:
here is the back trace:
write(1, "Setting PRLDAP_OPT_IO_MAX_TIMEOUT"..., 34Setting
PRLDAP_OPT_IO_MAX_TIMEOUT
) = 34
write(1, "Error setting the PR timeout opti"..., 52Error setting the PR
timeout option : Unknown error
) = 52
write(1, "PRLDAP_OPT_IO_MAX_TIMEOUT Set\n"..., 30PRLDAP_OPT_IO_MAX_TIMEOUT
Set
) = 30
write(1, "Setting LDAP_OPT_RECONNECT\n"..., 27Setting LDAP_OPT_RECONNECT
) = 27
write(1, "LDAP_OPT_RECONNECT Set\n"..., 23LDAP_OPT_RECONNECT Set
) = 23
write(1, "Getting LDAP_OPT_RECONNECT\n"..., 27Getting LDAP_OPT_RECONNECT
) = 27
write(1, "Value of LDAP_OPT_RECONNECT : 1\n"..., 32Value of
LDAP_OPT_RECONNECT : 1
) = 32
write(1, "Getting PRLDAP_OPT_IO_MAX_TIMEOUT"..., 34Getting
PRLDAP_OPT_IO_MAX_TIMEOUT
) = 34
write(1, "Value of PRLDAP_OPT_IO_MAX_TIMEOU"..., 39Value of
PRLDAP_OPT_IO_MAX_TIMEOUT : 0
) = 39
write(1, "Setting Protocol Version\n"..., 25Setting Protocol Version
) = 25
write(1, "Protocol Version Set\n"..., 21Protocol Version Set
) = 21
write(1, "Binding to DS\n"..., 14Binding to DS
) = 14
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(1389),
sin_addr=inet_addr("10.220.16.220")}, 16) = -1 EINPROGRESS (Operation now in
progress)
poll([{fd=3, events=POLLOUT}], 1, 10000) = 1 ([{fd=3, revents=POLLOUT}])
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
fcntl64(3, F_SETFL, O_RDWR) = 0
time(NULL) = 1241901653
write(3, "0\31\2\1\1`\24\2\1\3\4\10cn=admin\200\5oblix"..., 27) = 27
poll([{fd=3, events=POLLIN}, {fd=-1}, {fd=-1}, {fd=-1}, {fd=-1}], 5, -1
Thanks,
Denish
On Mon, May 11, 2009 at 6:20 PM, Anton Bobrov <[email protected]> wrote:
that is to be expected. unless you somehow manage to overflow related
OS buffers by continuously sending data i expect you should be able
to resume it cleanly. can you post full backtrace on the client side
showing which call is blocking exactly ?
denish patel wrote:
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
