RamaKrishna Narla | 2 Jan 2007 15:15
Picon

ldap_simple_bind call blocks with SSL connection, when DS hangs

Hi,

We are using Mozilla LDAP C SDK 5.12 in our application. We are
currently switching from synchronous calls to asynchronous calls.

When Directory Server hangs, it is known that clients using synchronous
calls like ldap_simple_bind_s will hang/block in LDAP SDK calls.
Ideally, this should not be the behavior with the asynchronous calls
like ldap_simple_bind.

But, we are observing that when Directory Server hangs, our application
is blocking in ldap_simple_bind call when connection used is in SSL
mode.
Also note that, in the same scenario, our application is not blocking
when connection is in Open mode.
Is anybody observed such a behavior? Any insights on this problem are
welcome.

Thanks in advance,
Ramakrishna.
Anton Bobrov | 2 Jan 2007 16:13
Picon

Re: ldap_simple_bind call blocks with SSL connection, when DS hangs


you gonna have to elaborate on "hang/block" thing ie if you attach
debugger to it and do a backtrace where is it at ? do you set any
timeout values properly like LDAP_X_OPT_CONNECT_TIMEOUT etc ?

RamaKrishna Narla wrote:
> Hi,
> 
> We are using Mozilla LDAP C SDK 5.12 in our application. We are
> currently switching from synchronous calls to asynchronous calls.
> 
> When Directory Server hangs, it is known that clients using synchronous
> calls like ldap_simple_bind_s will hang/block in LDAP SDK calls.
> Ideally, this should not be the behavior with the asynchronous calls
> like ldap_simple_bind.
> 
> But, we are observing that when Directory Server hangs, our application
> is blocking in ldap_simple_bind call when connection used is in SSL
> mode.
> Also note that, in the same scenario, our application is not blocking
> when connection is in Open mode.
> Is anybody observed such a behavior? Any insights on this problem are
> welcome.
> 
> Thanks in advance,
> Ramakrishna.
> 
> _______________________________________________
> dev-tech-ldap mailing list
> dev-tech-ldap <at> lists.mozilla.org
(Continue reading)

RamaKrishna Narla | 5 Jan 2007 18:05
Picon

Re: ldap_simple_bind call blocks with SSL connection, when DS hangs

Hi Anton,

Thanks for your reply.

Backtrace of the blocked thread is as follows:

 # ChildEBP RetAddr  Args to Child
00 03ac83bc 7c59a072 00000304 00000000 00000000
ntdll!ZwWaitForSingleObject+0xb (FPO: [3,0,0])
01 03ac83e4 7c57b3e9 00000304 ffffffff 00000000
KERNEL32!WaitForSingleObjectEx+0x71 (FPO: [Non-Fpo])
02 03ac83f4 30036d02 00000304 ffffffff 0137d9de
KERNEL32!WaitForSingleObject+0xf (FPO: [2,0,0])
03 03ac841c 30038399 0229ae50 ffffffff 00000001
libobnspr4!_PR_MD_WAIT(struct PRThread * thread = 0x0229ae50, unsigned
int ticks = 0xffffffff)+0x72 (FPO: [Non-Fpo]) (CONV: cdecl)
[j:\sdk\mozilla\source\mozilla_new_home\ldapsdkcode\mozilla\nsprpub\pr\src\md\windows\ntio.c
 <at>  528]
04 03ac8430 30039c71 0229ae50 ffffffff 0229ae50
libobnspr4!_NT_IO_WAIT(struct PRThread * thread = 0x0229ae50, unsigned
int timeout = 0xffffffff)+0xe9 (FPO: [Non-Fpo]) (CONV: cdecl)
[j:\sdk\mozilla\source\mozilla_new_home\ldapsdkcode\mozilla\nsprpub\pr\src\md\windows\ntio.c
 <at>  743]
05 03ac8454 30026cac 04a70138 04b2377c 00000005
libobnspr4!_PR_MD_RECV(struct PRFileDesc * fd = 0x04a70138, void * buf
= 0x04b2377c, int amount = 5, int flags = 0, unsigned int timeout =
0xffffffff)+0x2f1 (FPO: [Non-Fpo]) (CONV: cdecl)
[j:\sdk\mozilla\source\mozilla_new_home\ldapsdkcode\mozilla\nsprpub\pr\src\md\windows\ntio.c
 <at>  1756]
06 03ac847c 30008286 04a70138 04b2377c 00000005
(Continue reading)

Anton Bobrov | 8 Jan 2007 12:58
Picon

Re: ldap_simple_bind call blocks with SSL connection, when DS hangs


you might wanna try the following before starting any operations :

/* set the max I/O timeout option to 5 seconds */
if ( prldap_set_session_option( NULL, NULL, PRLDAP_OPT_IO_MAX_TIMEOUT,
                                                5000 /* 5 secs */ ) !=
LDAP_SUCCESS ) {
		ldap_perror( NULL,
                 "prldap_set_session_option PRLDAP_OPT_IO_MAX_TIMEOUT" );
                 exit( 1 );
           	}

i think you are also confused by the meaning of libldap async calls
because you seem to think that they imply async i/o which they dont
actually. LDAP_X_OPT_CONNECT_TIMEOUT option means exactly what it
says ie it sets connect timeout on libldap client side.

RamaKrishna Narla wrote:
> Hi Anton,
> 
> Thanks for your reply.
> 
> Backtrace of the blocked thread is as follows:
> 
>  # ChildEBP RetAddr  Args to Child
> 00 03ac83bc 7c59a072 00000304 00000000 00000000
> ntdll!ZwWaitForSingleObject+0xb (FPO: [3,0,0])
> 01 03ac83e4 7c57b3e9 00000304 ffffffff 00000000
> KERNEL32!WaitForSingleObjectEx+0x71 (FPO: [Non-Fpo])
> 02 03ac83f4 30036d02 00000304 ffffffff 0137d9de
(Continue reading)

Rich Megginson | 8 Jan 2007 21:33

Please review: add libldif to public libs

https://bugzilla.mozilla.org/show_bug.cgi?id=366335

This is pretty straightforward, adding another public library and public 
header file.  I also bumped the mozldap version to 6.0.1.
Ramakrishna B | 9 Jan 2007 01:09
Picon
Favicon

Setting Timeout for ldap_simple_bind() in SSL mode

Hi,

  We are using Netscape 5.12.
  We are facing an issue with ldap_simple_bind() asynchronous call in SSL mode.
  Any help in this matter would be greatly appreciated.
  Is there a way to set a timeout for ldap_simple_bind() asynchronous call (operating 
  in SSL Mode) so that it does not get blocked if LDAP server hanges.
  Currently during the ldap_simple_bind() call, the Netscape SDK seems to do a 
  SSL handshake to exchange messages and due to LDAP server hang,
  the ldap_simple_bind() call hangs.
  Is there a way we can set some timelimit to this function call so that
  we can failover to a different server in such scenarios ?
  It would be great if we can have the control on the client side itself.

Following is the stack that we are seeing:

  ntdll!ZwWaitForSingleObject+0xb (FPO: [3,0,0])
KERNEL32!WaitForSingleObjectEx+0x71 (FPO: [Non-Fpo])
KERNEL32!WaitForSingleObject+0xf (FPO: [2,0,0])
libobnspr4!_PR_MD_WAIT(struct PRThread * thread = 0x0229ae50, unsigned int ticks = 0xffffffff)+0x72
(FPO: [Non-Fpo]) (CONV: cdecl)
[j:\sdk\mozilla\source\mozilla_new_home\ldapsdkcode\mozilla\nsprpub\pr\src\md\windows\ntio.c
 <at>  528]
libobnspr4!_NT_IO_WAIT(struct PRThread * thread = 0x0229ae50, unsigned int timeout =
0xffffffff)+0xe9 (FPO: [Non-Fpo]) (CONV: cdecl)
[j:\sdk\mozilla\source\mozilla_new_home\ldapsdkcode\mozilla\nsprpub\pr\src\md\windows\ntio.c
 <at>  743]
libobnspr4!_PR_MD_RECV(struct PRFileDesc * fd = 0x04a70138, void * buf = 0x04b2377c, int amount = 5, int
flags = 0, unsigned int timeout = 0xffffffff)+0x2f1 (FPO: [Non-Fpo]) (CONV: cdecl)
[j:\sdk\mozilla\source\mozilla_new_home\ldapsdkcode\mozilla\nsprpub\pr\src\md\windows\ntio.c
(Continue reading)

Anton Bobrov | 9 Jan 2007 01:34
Picon

Re: Setting Timeout for ldap_simple_bind() in SSL mode


i thought i just answered this but under diff subj.
PRLDAP_OPT_IO_MAX_TIMEOUT should do the trick here,
see my prev msg for more details.

Ramakrishna B wrote:
> Hi,
>    
>   We are using Netscape 5.12.
>   We are facing an issue with ldap_simple_bind() asynchronous call in SSL mode.
>   Any help in this matter would be greatly appreciated.
>   Is there a way to set a timeout for ldap_simple_bind() asynchronous call (operating 
>   in SSL Mode) so that it does not get blocked if LDAP server hanges.
>   Currently during the ldap_simple_bind() call, the Netscape SDK seems to do a 
>   SSL handshake to exchange messages and due to LDAP server hang,
>   the ldap_simple_bind() call hangs.
>   Is there a way we can set some timelimit to this function call so that
>   we can failover to a different server in such scenarios ?
>   It would be great if we can have the control on the client side itself.
>   
> Following is the stack that we are seeing:
>    
>   ntdll!ZwWaitForSingleObject+0xb (FPO: [3,0,0])
> KERNEL32!WaitForSingleObjectEx+0x71 (FPO: [Non-Fpo])
> KERNEL32!WaitForSingleObject+0xf (FPO: [2,0,0])
> libobnspr4!_PR_MD_WAIT(struct PRThread * thread = 0x0229ae50, unsigned int ticks = 0xffffffff)+0x72
(FPO: [Non-Fpo]) (CONV: cdecl)
[j:\sdk\mozilla\source\mozilla_new_home\ldapsdkcode\mozilla\nsprpub\pr\src\md\windows\ntio.c
 <at>  528]
> libobnspr4!_NT_IO_WAIT(struct PRThread * thread = 0x0229ae50, unsigned int timeout =
(Continue reading)

RamaKrishna Narla | 10 Jan 2007 14:16
Picon

Re: ldap_simple_bind call blocks with SSL connection, when DS hangs

Hi Anton,

Many thanks for your valuable response. Your suggestion worked well for
us. After setting PRLDAP_OPT_IO_MAX_TIMEOUT to a finite value, our
servers are not blocking during SSL handshake, when DS is in hang
state.

Yes, LDAP_X_OPT_CONNECT_TIMEOUT setting is honoured by LDAP SDK client
itself. I mistakenly felt that you are talking about
LDAP_OPT_TIMELIMIT, and hence said that, it is implemented by the LDAP
server.

What is the default value of PRLDAP_OPT_IO_MAX_TIMEOUT parameter? Is it
LDAP_X_IO_TIMEOUT_NO_TIMEOUT (i.e., -1)?
Before to ldap simple bind operation, we are setting
PRLDAP_OPT_IO_MAX_TIMEOUT to a finite value, so that, during SSL
handshake our server do not block, if DS is in hang. Once this bind
operation is completed, we are planning to reset the
PRLDAP_OPT_IO_MAX_TIMEOUT parameter to its original value.

I have actually already tried by resetting PRLDAP_OPT_IO_MAX_TIMEOUT to
-1 after completion of bind operation, and didn't come across any new
block when DS is in hang state. Are you aware of any other issues that
we may face later, as we are resetting the PRLDAP_OPT_IO_MAX_TIMEOUT
parameter to -1.

Thanks,
Ramakrishna.

Anton Bobrov wrote:
(Continue reading)

Anton Bobrov | 10 Jan 2007 14:43
Picon

Re: ldap_simple_bind call blocks with SSL connection, when DS hangs


> What is the default value of PRLDAP_OPT_IO_MAX_TIMEOUT parameter? Is it
> LDAP_X_IO_TIMEOUT_NO_TIMEOUT (i.e., -1)?

yep, thats it.

> I have actually already tried by resetting PRLDAP_OPT_IO_MAX_TIMEOUT to
> -1 after completion of bind operation, and didn't come across any new
> block when DS is in hang state. Are you aware of any other issues that
> we may face later, as we are resetting the PRLDAP_OPT_IO_MAX_TIMEOUT
> parameter to -1.

thats most likely because of session/handle defaults when you set a
default value not specific to any particular session/handle it will
only apply to new handles/sessions created after the value has been
set. to change the value on a session/handle that already exist you
should pass related argument/s to prldap_set_session_option instead
eg prldap_set_session_option( ld, [...the rest...]). give it a try.
Rich Megginson | 10 Jan 2007 17:24

Merge latest Sun code onto trunk?

Anton, how much more code do you need to merge in?  Should we go ahead 
and create a 6.1.0 release, or do you want to wait for more code to go in?

Gmane