JDK-8217606 : LdapContext#reconnect always opens a new connection
  • Type: Bug
  • Component: core-libs
  • Sub-Component: javax.naming
  • Affected Version: 9,11,12,13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-01-15
  • Updated: 2024-04-08
  • Resolved: 2019-08-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13 JDK 14 JDK 8 Other
11.0.8-oracleFixed 13.0.4Fixed 14 b10Fixed 8u261Fixed openjdk8u272Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
ADDITIONAL SYSTEM INFORMATION :
Behavior should be the same for all OS versions.

A DESCRIPTION OF THE PROBLEM :
The LdapContext#reconnect method allows LDAP clients to initiate an LDAP bind operation on the existing connection. Invoking this method should not open a new connection under those circumstances.

The change in this commit: https://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/021b47694183
adds a reconnect flag that does not discriminate, causing a new connection to be opened even in the case of performing a bind.

I believe further analysis will show that the previous open connection is also orphaned, that is it does not get properly torn down.

REGRESSION : Last worked in version 8u191

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
You will need an LDAP server and an entry on that server with ACLs that allow you to bind as that entry.
Compile and execute the supplied source code, providing (3) command line arguments:
1) the URL for the LDAP server
2) the DN of the entry to bind as
3) the password for the DN

From a command line execute:
java JndiReconnectBug ldap://my.ldap-server.domain 'uid=test,ou=account,dc=org,dc=domain' 'password'

During the first sleep, examine the open connections from your host to the directory.
(netstat is a common tool for this)
During the second sleep, examine the open connections again


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
During the first sleep you will see the open connection created by instantiating the InitialLdapContext.

During the second sleep you will see the same connection that has performed an LDAP bind operation.

ACTUAL -
During the first sleep you will see the open connection created by instantiating the InitialLdapContext.

During the second sleep you will see the original connection and a new connection created by the call to reconnect.

---------- BEGIN SOURCE ----------
import java.nio.charset.StandardCharsets;
import java.util.Hashtable;
import javax.naming.ldap.InitialLdapContext;

public final class JndiReconnectBug
{
  public static void main(String[] args) throws Exception {
    Hashtable<String, Object> env = new Hashtable<>();
    env.put("java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory");
    env.put("java.naming.ldap.version", "3");
    env.put("java.naming.provider.url", args[0]);

    // open connection
    InitialLdapContext context = new InitialLdapContext(env, null);
    System.out.println("Check open connections");
    Thread.sleep(10000);

    // send bind request
    context.addToEnvironment("java.naming.security.authentication", "simple");
    context.addToEnvironment("java.naming.security.principal", args[1]);
    context.addToEnvironment("java.naming.security.credentials", args[2].getBytes(StandardCharsets.UTF_8));
    context.reconnect(null);
    System.out.println("Check open connections");
    Thread.sleep(10000);
  }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
No work around found.


FREQUENCY : always



Comments
Fix Request (8u) I would like to backport this patch for parity with Oracle 8u271. The original patch does not apply cleanly. Code review thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012123.html (reviewed)
14-07-2020

Fix request (13u) Requesting backport to 13u for parity with 11u, applies cleanly.
26-05-2020

Fix request (11u) I would like to downport this for parity with 11.0.8-oracle. Applies clean.
28-02-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/6717d7e59db4 User: prappo Date: 2019-08-14 10:47:24 +0000
14-08-2019

I'm not sure about this issue being P2. I can't see anything in the spec (LdapContext/LdapContext.reconnect) about a guaranteed connection reuse in those circumstances. Instead, it seems to be long-standing behaviour.
03-07-2019