RFR: 8357708: com.sun.jndi.ldap.Connection ignores queued LDAP replies if Connection is subsequently closed [v6]

[Jaikiran Pai]

On Fri, 12 Sep 2025 16:04:59 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8357708?
>> 
>> As noted in the issue, the current code in `com.sun.jndi.ldap.Connection.readReply()` is susceptible to throwing a `ServiceUnavailableException` even when the LDAP replies have already been received and queued for processing. The JBS issue has additional details about how that can happen.
>> 
>> The commit in this PR simplifies the code in `com.sun.jndi.ldap.LdapRequest` to make sure it always gives out the replies that have been queued when the `LdapRequest.getReplyBer()` gets invoked. One of those queued values could be markers for a cancelled or closed request. In that case, the `getReplyBer()`, like previously, continues to throw the right exception. With this change, the call to `replies.take()` or `replies.poll()` (with an infinite timeout) is no longer expected to hang forever, if the `Connection` is closed (or the request cancelled). This then allows us to remove the connection closure (`sock == null`) check in `Connection.readReply()`.
>> 
>> A new jtreg test has been introduced to reproduce this issue and verify the fix. The test reproduces this issue consistently when the source fix isn't present. With the fix present, even after several thousand runs of this test, the issue no longer reproduces.
>> 
>> tier1, tier2 and tier3 tests continue to pass with this change. I've marked the fix version of this issue for 26 and I don't plan to push this for 25.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - move the new test under test/jdk/com/sun/jndi/ldap
>  - Aleksei's review - use public/standard APIs instead of internal com.sun.jndi.ldap.LdapCtx

Hello Aleksei, I have updated the PR to implement your suggestion 1 and 2. As for the other suggestion of moving these constants to the `LDAPTestUtils` test library class, I think that's a good idea too. However, I gave that a try and that isn't straightforward. Once I move them to that class, jtreg then requires me to add a `@build` and a `@library` instruction to bring in the `test.LDAPServer` class which the `LDAPTestUtils` uses (but not this new test). That wouldn't be too bad and I did add those, but then `LDAPTestUtils` has an import of an internal class:


import com.sun.jndi.ldap.LdapURL

so that then forces me to reintroduce the:

@modules java.naming/com.sun.jndi.ldap

in this new test, which I think defeats the entire cleanup. So I decided to leave those constants this in this test class for now and reconsider that move as a future work. Would that be OK?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25449#issuecomment-3285898790