to many open files

Hi gurus i have a problem on ssl ldap and and and the file descriptors:

OS: SunSolaris 8

Version1.4.2

ID JDK

Build Level1.4.2_04-b05

Build Date06/27/2004

the strange problem is related on too many open files and file descriptors

when a first user login and logoff no related broblems on the /WEB-INF/cacerts files but when a second user login and log off

the files remains open and the output log give the i too many open files the log

]b44131 LdapRegistryI Could not get the users matching the pattern AW504P28 because of the following exception javax.naming.CommunicationException: webldap.IP:PORT [Root exception is java.net.SocketException: Too many open files]

at com.sun.jndi.ldap.Connection.<init>(Connection.java:204)

at com.sun.jndi.ldap.LdapClient.<init>(LdapClient.java:119)

at com.sun.jndi.ldap.LdapClient.getInstance(LdapClient.java:1668)

at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2599)

at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:290)

at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:175)

at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:193)

at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:136)

at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:66)

at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:662)

at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:243)

at javax.naming.InitialContext.init(InitialContext.java:219)

at javax.naming.InitialContext.<init>(InitialContext.java:195)

at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:80)

at com.ibm.ws.security.registry.ldap.LdapConfig.getRootDSE(LdapConfig.java:287)

at com.ibm.ws.security.registry.ldap.LdapRegistryImpl.getRootDSE(LdapRegistryImpl.java:181)

at com.ibm.ws.security.registry.ldap.LdapRegistryImpl.search(LdapRegistryImpl.java:1622)

at com.ibm.ws.security.registry.ldap.LdapRegistryImpl.search(LdapRegistryImpl.java:1564)

at com.ibm.ws.security.registry.ldap.LdapRegistryImpl.search(LdapRegistryImpl.java:1559)

at com.ibm.ws.security.registry.ldap.LdapRegistryImpl.getUsers(LdapRegistryImpl.java:1105)

at com.ibm.ws.security.registry.ldap.LdapRegistryImpl.checkPassword(LdapRegistryImpl.java:256)

at com.ibm.ws.security.registry.UserRegistryImpl.checkPassword(UserRegistryImpl.java:277)

at com.ibm.ws.security.ltpa.LTPAServerObject.authenticate(LTPAServerObject.java:565)

at com.ibm.ws.security.server.lm.ltpaLoginModule.login(ltpaLoginModule.java:411)

at com.ibm.ws.security.common.auth.module.proxy.WSLoginModuleProxy.login(WSLoginModuleProxy.java:122)

at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:324)

at javax.security.auth.login.LoginContext.invoke(LoginContext.java:675)

at javax.security.auth.login.LoginContext.access$000(LoginContext.java:129)

at javax.security.auth.login.LoginContext$4.run(LoginContext.java:610)

at java.security.AccessController.doPrivileged(Native Method)

at javax.security.auth.login.LoginContext.invokeModule(LoginContext.java:607)

at javax.security.auth.login.LoginContext.login(LoginContext.java:534)

at com.ibm.ws.security.auth.JaasLoginHelper.jaas_login(JaasLoginHelper.java:307)

at com.ibm.ws.security.auth.JaasLoginHelper.jaas_login(JaasLoginHelper.java:349)

at com.ibm.ws.security.auth.ContextManagerImpl.login(ContextManagerImpl.java:1001)

at com.ibm.ws.security.auth.ContextManagerImpl.login(ContextManagerImpl.java:853)

at com.ibm.ws.security.auth.ContextManagerImpl.login(ContextManagerImpl.java:844)

at com.ibm.ws.security.auth.ContextManagerImpl.getServerSubject(ContextManagerImpl.java:1701)

at com.ibm.ws.management.util.SecurityHelper.getServerSubject(SecurityHelper.java:539)

at com.ibm.ws.management.event.NotificationDispatcher$2.run(NotificationDispatcher.java:247)

at java.security.AccessController.doPrivileged(Native Method)

at com.ibm.ws.management.event.NotificationDispatcher$DispatchANotificationToAListener.setServerCredentials(NotificationDispatcher.java:245)

at com.ibm.ws.management.event.NotificationDispatcher$DispatchANotificationToAListener.run(NotificationDispatcher.java:215)

at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:912)

Caused by: java.net.SocketException: Too many open files

at java.net.Socket.createImpl(Socket.java:331)

at java.net.Socket.<init>(Socket.java:304)

at java.net.Socket.<init>(Socket.java:124)

at com.sun.jndi.ldap.Connection.createSocket(Connection.java:346)

at com.sun.jndi.ldap.Connection.<init>(Connection.java:181)

what is the cause?

thank you

AP

[5097 byte] By [alessioporcacchiaa] at [2007-11-27 5:22:22]
# 1
> > what is the cause?Leaking resources of some kind. Possibly leaking sockets.
cotton.ma at 2007-7-12 11:47:44 > top of Java-index,Java Essentials,Java Programming...
# 2
cotton for you is a ssl socket problems?because i think is in a jdk (old release) if update this i can resolve the problem? i a bug?thank yu cot
alessioporcacchiaa at 2007-7-12 11:47:44 > top of Java-index,Java Essentials,Java Programming...
# 3
There is no evidence that it has anything to do with ' the /WEB-INF/cacerts files'. The stack trace is coming from an LDAP access which uses sockets.Close some sockets or some files.
ejpa at 2007-7-12 11:47:44 > top of Java-index,Java Essentials,Java Programming...
# 4

On Un*x (including Solaris) sockets use the same file descriptors as files (and pipes etc.)

In the pesudo-file-system /proc you can find information about the open descriptors of your process, in this example about the shell (its own process id is denoted by $$). The shell happens to have only the stdin, stdout, stderr desciptors open:

$ ls -l /proc/$$/fd

total 0

c1 posmantty24, 2 May 24 13:34 0

c1 posmantty24, 2 May 24 13:34 1

c1 posmantty24, 2 May 24 13:34 2

BIJ001a at 2007-7-12 11:47:44 > top of Java-index,Java Essentials,Java Programming...
# 5

sorry i can explain well the issue

for our experience

LDAP access causes the opening a lot of file descriptor?

The LDAP proves ist still running and is still opening files. Meanwhile, because of the SSL communication with application, some files are Created in the CACERTS directory

Suddenly, the OS has reached its file descriptor limit: an error message 揟oo many open files?appears

Question: the situation is : that files cannot be closed in the CACERT director, because the OS has not more file descriptors (because the ldap process has used all file descriptors to the limit)?

is related on LDAP this problem?

thank you for your kindness guys!

AP

alessioporcacchiaa at 2007-7-12 11:47:44 > top of Java-index,Java Essentials,Java Programming...
# 6
First do what BIJ001 said to find out what is really open.btw thanks for posting that bit of info, BIJ001, I ran into this problem several years ago. It's definately somehting to remember if I see it again.
robtafta at 2007-7-12 11:47:44 > top of Java-index,Java Essentials,Java Programming...
# 7

> sorry i can explain well the issue

>

Alessio,

I think you need a forum in your own language. It's hard to understand what you are saying but from what I do understand it seems clear to me that you aren't understanding really what we are saying.

Sorry.

Vada italiano forum. I non capisca voi.

Scuse

cotton.ma at 2007-7-12 11:47:44 > top of Java-index,Java Essentials,Java Programming...
# 8

sorry!

I have not explained the problem in English well?

i know but the best java developer speak english :)

i forget to say a important clue:

when i don't use the ssl connection i don't have the file descriptor problem.

Really strange.

Ps

sorry cot :)

alessioporcacchiaa at 2007-7-12 11:47:44 > top of Java-index,Java Essentials,Java Programming...