LDAP TCP Connection remains after traffic is completed - unboundid-ldapsdk-3.2.1.

[skathir1]

During Burst traffic around 4k LDAP connection are created per seconds , after traffic is completed , in Application we are closing those open LDAP connection.

After that we observed few connection is still remains and not getting closed(netstat command).

SDK : unboundid-ldapsdk-3.2.1

Connection code:

connection = serverSet.getConnection(getCurrentHealthCheck(getConfig()));   

private LDAPConnectionPoolHealthCheck getCurrentHealthCheck(
        final LdapServerConfiguration config) {
    LDAPConnectionPoolHealthCheck healthCheck = new LDAPConnectionPoolHealthCheck()
    {

        @Override
        public void ensureNewConnectionValid(LDAPConnection connection)
                throws LDAPException {

            BindResult result = connection.bind(getInitBindRequest(config));

        }

    };
    return healthCheck;
}

[dirmgr]

It's not clear which version you're actually using, since there was no 3.7.1 release. However, I'm not aware of any case in which the LDAP SDK hasn't closed the underlying TCP connection after closing the connection. The LDAP SDK is very heavily used, and no one else has ever reported issues in which connections aren't actually closed after a proper request to do so.

It's probably the case that the connection isn't actually open, but that the operating system's TCP stack is still maintaining a reference to it for a period of time (usually about four minutes). This is normal, and netstat will show the connection, but it will likely be in a state like TIME_WAIT (indicating that the local system has initiated a close on it) rather than ESTABLISHED (indicating that the connection is still established). The TIME_WAIT state helps ensure that a new connection doesn't reuse the same combination of the local address, local port, remote address, and remote port too soon after an earlier connection, which could potentially cause problems if there are still delayed packets in transit from the peer, or if the peer never got or acknowledged the notice of the connection closure.

If you do see that there are connections still in an ESTABLISHED state after you expected all of them to be closed, then it would be helpful if you could provide a simple standalone program that demonstrates this.

[skathir1]

Thanks for your reply.I have corrected SDK version in subject.I will try to reproduce this issue with Standalone program and let you know.