-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
11.0.4
-
x86_64
-
linux
ADDITIONAL SYSTEM INFORMATION :
Centos 7 / 64 bits / OpenJDK11.0.4
Tomcat 8.5
A DESCRIPTION OF THE PROBLEM :
There is some changes to this classe that cause a leak on sockets.
The issue is probably OS independent.
Class is com.sun.jndi.ldap.LdapCtx on private method connect.
In case of reconnection attempt, a new LdapClient (that create a new socket) is instancied and the previous socket maintained by the previous LdapClient is not closed.
A patch should be like that :
if (reconnect && clnt != null) {
clnt.closeConnection();
}
clnt = LdapClient.getInstance(...)
REGRESSION : Last worked in version 8u212
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a login.config to authorize tomcat to connect to an ldap server (active directory in my case but it's clearly independent), use this config in a JMX context.
Use a JMX client (java mission control in my case) which retrieve informations about tomcat MBean and have a look to TCP connections by using lsof linux command.
Exit from JMX client, sockets on ldap remains (ESTABLISHED)
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Sockets should be closed, I'm not using socket pooling.
ACTUAL -
Sockets remains opened for a long time (GC probably destroy java Socket objects and OS sockets by the way).
FREQUENCY : always
Centos 7 / 64 bits / OpenJDK11.0.4
Tomcat 8.5
A DESCRIPTION OF THE PROBLEM :
There is some changes to this classe that cause a leak on sockets.
The issue is probably OS independent.
Class is com.sun.jndi.ldap.LdapCtx on private method connect.
In case of reconnection attempt, a new LdapClient (that create a new socket) is instancied and the previous socket maintained by the previous LdapClient is not closed.
A patch should be like that :
if (reconnect && clnt != null) {
clnt.closeConnection();
}
clnt = LdapClient.getInstance(...)
REGRESSION : Last worked in version 8u212
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a login.config to authorize tomcat to connect to an ldap server (active directory in my case but it's clearly independent), use this config in a JMX context.
Use a JMX client (java mission control in my case) which retrieve informations about tomcat MBean and have a look to TCP connections by using lsof linux command.
Exit from JMX client, sockets on ldap remains (ESTABLISHED)
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Sockets should be closed, I'm not using socket pooling.
ACTUAL -
Sockets remains opened for a long time (GC probably destroy java Socket objects and OS sockets by the way).
FREQUENCY : always
- duplicates
-
JDK-8217606 LdapContext#reconnect always opens a new connection
-
- Closed
-