HI All,

I am facing some problem in application. We have configured mulitiple LDAP repositories under fedarated registry.

We have configured successfully and application was working fine. But i am getting the below errors in DMGR logs.
Same errors i am getting in application server systemout logs. We are facing some applicatoin slowness. Some threads are creating.

DMGR logs :
[4/2/13 15:18:19:861 GMT+05:30] 00000035 LdapConnectio I com.ibm.ws.wim.adapter
.ldap.LdapConnection DirContext reCreateDirContext(String errorMessage) CWWIM456
4I The user registry is now connected to 'ldaps://170.224.42.135:636' LDAP Serve
r.
[4/21/13 15:18:20:526 GMT+05:30] 00000035 exception     E com.ibm.ws.wim.adapter
.ldap.LdapConnection DirContext reCreateDirContext(String errorMessage) CWWIM452
0E The 'javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: L
dapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece]; re
solved object com.sun.jndi.ldap.LdapCtx@6dae6dae' naming exception occurred duri
ng processing.
[4/21/13 15:18:20:538 GMT+05:30] 00000035 exception     E com.ibm.ws.wim.adapter
.ldap.LdapConnection DirContext reCreateDirContext(String errorMessage)
                                 com.ibm.websphere.wim.exception.WIMSystemExcept
ion: CWWIM4520E The 'javax.naming.AuthenticationException: [LDAP: error code 49
- 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 5
25, vece]; resolved object com.sun.jndi.ldap.LdapCtx@6dae6dae' naming exception
occurred during processing.

AppServer Logs :

[4/22/13 3:02:39:461 GMT+05:30] 00000032 ThreadMonitor W   WSVR0605W: Thread "We
bContainer : 37505" (0000ba8d) has been active for 623122 milliseconds and may b
e hung.  There is/are 19 thread(s) in total in the server that may be hung.
        at com.ibm.ws.wim.adapter.ldap.LdapConnection.reCreateDirContext(LdapCon
nection.java:695)
        at com.ibm.ws.wim.adapter.ldap.LdapConnection.search(LdapConnection.java
:2822)
        at com.ibm.ws.wim.adapter.ldap.LdapConnection.checkSearchCache(LdapConne
ction.java:2707)
        at com.ibm.ws.wim.adapter.ldap.LdapConnection.search(LdapConnection.java
:2889)
        at com.ibm.ws.wim.adapter.ldap.LdapConnection.searchEntities(LdapConnect
ion.java:3042)
        at com.ibm.ws.wim.adapter.ldap.LdapAdapter.login(LdapAdapter.java:2730)
        at com.ibm.ws.wim.ProfileManager.loginImpl(ProfileManager.java:3478)
        at com.ibm.ws.wim.ProfileManager.genericProfileManagerMethod(ProfileMana
ger.java:309)
        at com.ibm.ws.wim.ProfileManager.login(ProfileManager.java:417)
        at com.ibm.websphere.wim.ServiceProvider.login(ServiceProvider.java:482)

[4/22/13 2:23:39:108 GMT+05:30] 00000035 ThreadMonitor W   WSVR0605W: Thread "We
bContainer : 37472" (0000ba67) has been active for 667705 milliseconds and may b
e hung.  There is/are 19 thread(s) in total in the server that may be hung.
        at com.ibm.jsse2.pc.h(pc.java:197)
        at com.ibm.jsse2.pc.a(pc.java:318)
        at com.ibm.jsse2.j.write(j.java:7)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:88
)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:146)
        at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:429)
        at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:366)
        at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:224)
        at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2697)
        at com.sun.jndi.ldap.LdapCtx.(LdapCtx.java:316)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:190)
        at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:208
)
        at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.ja
va:151)
@:151)
        at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.jav
a:81)
        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:6
79)
        at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:259
)
        at javax.naming.InitialContext.init(InitialContext.java:235)
        at javax.naming.ldap.InitialLdapContext.(InitialLdapContext.java:1
46)
        at com.ibm.ws.wim.adapter.ldap.TimedDirContext.(TimedDirContext.ja
va:68)
        at com.ibm.ws.wim.adapter.ldap.LdapConnection.createDirContext(LdapConne
ction.java:736)
        at com.ibm.ws.wim.adapter.ldap.LdapConnection.createContextPool(LdapConn
ection.java:555)
        at com.ibm.ws.wim.adapter.ldap.LdapConnection.reCreateDirContext(LdapCon
nection.java:698)
        at com.ibm.ws.wim.adapter.ldap.LdapConnection.search(LdapConnection.java
:2822)

 Thanks,

Chinna

Hi chinna,


  You are having

  CWWIM4520E The 'javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece];

  525 is an User not found error.

  Check your binding user or your bind point in the LDAP.

  The slowness can be related to SSL connection with LDAPs (ldaps://170.224.42.135:636). If it's posibble try an no-SSL connection with LDAP to check

  Hope this helps. Tell us if the problem is solve, please.


Regards

Hi Gabriel,

There is no connection loss b/w Appserver to LDAP server  636 port. Can you please help me how can i touble shoot. This was working fine from 6 months onwards.

Is there any settings for tunning LDAP paramters, how can i improve LDAP search in multiple repositories.

Thanks,

Chinna.

Hi Chinna

1)if  your federated repository configuration, each repository is having one ldap servers or multiple ldap servers, then check this option Support referrals to other LDAP servers " make it as ignore if it follow.

check the above option and provide more details about your federated repository configuration.

Thanks

[quote author=116539749 post=531626959]Hi Chinna

1)if  your federated repository configuration, each repository is having one ldap servers or multiple ldap servers, then check this option Support referrals to other LDAP servers " make it as ignore if it follow.

check the above option and provide more details about your federated repository configuration.

Thanks[/quote]

Good point,  on target :-)

Above situation will happen when one of the configured federated repositories are down as well

Hi Adminuppala /Joseph,

Thanks for your inputs.

Support referrals to other LDAP servers "  is igrone. All LDAP servers are active.

I have not tunned any LDAP parameter to improve the performance. All values are default. Please help me, how can tune my LDAP parameters.


Thanks,
Chinna.

Chinna,


  Still having the error in the log?

  CWWIM4520E The 'javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece];

  or has solved?


Regards

Can you please attach the FFDC logs from DMGR.

Also, you are using ssl for the LDAP connection, this will have performance issues to the amount of time it takes for LDAP search. If the search operation times out then you get 'user not found/ 525' error.

You can either increase the timeout or try with non-ssl port and see of the issue persists.

Chinna,

  You can review this thread about performance problems with LDAP connections using SSL
  www.websphereusergroup.org/go/thread/vie...
 
  You can try to increase the timeout of the LDAPs connections by default 120 seconds. Maybe your thread is hung because this issue.
 
  Check this link for LDAP tunning guide.
  www-01.ibm.com/support/docview.wss?uid=s...
 
  and
 
  Connection Pooling Configuration
  docs.oracle.com/javase/jndi/tutorial/lda...
 
  Also check your LDAP servers tunnings guides.

  Hope this helps.
 
regards

Hi All,

Thanks for your inputs.

In LDAP repository, use connection pooling is disabled.  Can we enabel this. There no option to provide value for use connection pooling. How can in crease?

Thanks,

Chinna.

Chinna,

  If you enabled connection pooling based on the infocenter you must use SDK properties to configure.

  Use connection pooling
   
   Specifies whether to utilize the connection pooling function, which is provided in the Software Development Kit (SDK).
   Connection pooling is maintained by the Java run time. It is configured by system properties.
 
  You can use the next link to configure properties

  How can LDAP connection pooling be configured in WebSphere Application Server with Standalone LDAP repository
 
 
  Hope this helps.
 
Regards

Hi All,

Thanks for yuour inputs.

LDAP threads are creating in WAS. There is no CPU usaage in server. Because of threads, server gone to hang state. We are unable to stop/start server from  conolse and command prompt. We are using three LDAP repositories under fedareted registry.

ThreadMonitor W WSVR0605W: Thread "WebContainer : 301" (000002c5) has been active for 661982 milliseconds and may be hung. There is/are 13 thread(s) in total in the server that may be hung.

at com.ibm.ws.wim.adapter.ldap.LdapConnection.getDirContext(LdapConnection.java:1559)

at com.ibm.ws.wim.adapter.ldap.LdapConnection.search(LdapConnection.java:2788)

at com.ibm.ws.wim.adapter.ldap.LdapConnection.checkSearchCache(LdapConnection.java:2707)

at com.ibm.ws.wim.adapter.ldap.LdapConnection.search(LdapConnection.java:2889)

at com.ibm.ws.wim.adapter.ldap.LdapConnection.searchEntities(LdapConnection.java:3042)

at com.ibm.ws.wim.adapter.ldap.LdapAdapter.login(LdapAdapter.java:2730)

at com.ibm.ws.wim.ProfileManager.loginImpl(ProfileManager.java:3478)

at com.ibm.ws.wim.ProfileManager.genericProfileManagerMethod(ProfileManager.java:309)

at com.ibm.ws.wim.ProfileManager.login(ProfileManager.java:417)

 [5/14/13 0:13:29:199 GMT+05:30] 00000029 ThreadMonitor W WSVR0605W: Thread "WebContainer : 299" (000002c1) has been active for 679521 milliseconds and may be hung. There is/are 15 thread(s) in total in the server that may be hung.

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.read(SocketInputStream.java:155)

at com.ibm.jsse2.a.a(a.java:176)

at com.ibm.jsse2.a.a(a.java:143)

at com.ibm.jsse2.pc.a(pc.java:402)

at com.ibm.jsse2.pc.h(pc.java:570)

at com.ibm.jsse2.pc.a(pc.java:318)

at com.ibm.jsse2.j.write(j.java:7)

at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:88)

at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:146)

at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:429)

00000029 ThreadMonitor W WSVR0605W: Thread "WebContainer : 304" (000002d3) has been active for 672059 milliseconds and may be hung. There is/are 18 thread(s) in total in the server that may be hung.

at com.ibm.ws.wim.adapter.ldap.LdapConnection.getDirContext(LdapConnection.java:1559)

at com.ibm.ws.wim.adapter.ldap.LdapConnection.search(LdapConnection.java:2788)

at com.ibm.ws.wim.adapter.ldap.LdapConnection.checkSearchCache(LdapConnection.java:2707)

at com.ibm.ws.wim.adapter.ldap.LdapConnection.search(LdapConnection.java:2889)

at com.ibm.ws.wim.adapter.ldap.LdapConnection.searchEntities(LdapConnection.java:3042)

We have checked through netstat more ESTABLISHED connection are found.

tcp 0 0 116.90.249.27.55853 116.90.243.61.636 ESTABLISHED

tcp 0 0 116.90.249.27.55855 116.90.243.61.636 ESTABLISHED

tcp 0 0 116.90.249.27.34230 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.34233 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.34263 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.34414 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.34434 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.34437 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.34439 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.34443 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.61514 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.61516 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.61517 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.61519 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.61524 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.61529 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.61536 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.61546 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.61553 170.224.42.135.636 ESTABLISHED

tcp 0 0 116.90.249.27.61569 170.224.42.135.636 ESTABLISHED

Thanks,
Chinna.