On Mon, 9 Feb 2026 14:47:43 GMT, Jaikiran Pai <[email protected]> wrote:
> Can I please get a review of this change which proposes to fix the issue > reported in https://bugs.openjdk.org/browse/JDK-8362268? > > The underlying issue here is simple - A `javax.naming.Context` for LDAP is > backed by a JDK internal `com.sun.jndi.ldap.LdapCtx` instance. Each `LdapCtx` > uses a `com.sun.jndi.ldap.LdapClient` instance to do the LDAP operations. > Each `LdapClient` further uses a `com.sun.jndi.ldap.Connection` instance. > Each `Connection` instance uses a `Socket` and the socket's `InputStream` and > `OutputStream` to read/write LDAP messages from/to a LDAP server. Each > `Connection` instance spawns a `Thread` to read (over the InputStream) and > queue incoming messages from the LDAP server. > > When a LDAP backed `javax.naming.Context` initiates an operation, for example > a `Context.lookup()`, then internally the LdapCtx initiates a LDAP request > over the Connection's `OutputStream` and then waits for a LDAP response to > arrive. In the issue reported here, it so happens that while reading over the > `Connection`'s `InputStream`, the `InputStream.read()` raises an > `IOException` (for whatever reason). That `IOException` rightly initiates the > close of the `Connection` instance. Closing a `Connection` instance involves > queuing a marker response for all waiting thread(s) to notice and raise an > IOException, which they can ulimately propagate as a `NamingException` to the > application. Additionally, the closing of the `Connection` also closes the > `InputStream` and `OutputStream` of that `Connection`. > > When a thread that was waiting for a LDAP response, in LdapCtx, wakes up due > to an IOException, it attempts to send a "abandon request" LDAP message over > the `Connection`, so that the server knows that the client has abandoned the > request. Since the Connection and its Input/OutputStream(s) are already > closed, trying to write a message over the OutputStream can/will lead to an > exception. The implementation of `Connection.abandonRequest(LdapRequest ldr, > Control[] reqCtls)` which is where this code resides, guards against such > exceptions by catching and ignoring an `IOException` from an > `OutputStream.write(...)/flush()` call. > > Although `OutputStream.write(...)` is specified to throw an IOException if > that stream is already closed, not all implementations adhere to that > specification. For example, `java.io.BufferedOutputStream` does not throw any > exception when `write(...)` is invoked on a closed `OutputStream`. > Incidentally, the `Connection` instance's `OutputStream` is a `Bu... Unfortunately, my credentials for that forest have been removed severa months ago and for my new forest the admins are incapable to configure LDAPS although the entire CA chain is up and running. Though, I see two problems with the change: 1. You encode the `AbandonRequest` although it is not sent, that's waste 2. The BER stream is dumped to tracefile although not request is being sent, that is wrong. ------------- Changes requested by [email protected] (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/29638#pullrequestreview-3774365653
