On Fri, 12 Sep 2025 16:04:59 GMT, Jaikiran Pai <j...@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
