On Tue, 22 Apr 2025 11:08:15 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test only change which proposes to improve
>> the debuggability of `com/sun/jndi/ldap/LdapPoolTimeoutTest.java`?
>>
>> This test has been failing intermittently in our CI for several years.
>> Detailed a
On Tue, 3 Dec 2024 17:36:35 GMT, Aleksei Efimov wrote:
> JNDI dependency on the `java.applet.Applet` has been removed in JDK9 with
> [JDK-8051422](https://bugs.openjdk.org/browse/JDK-8051422). It made the
> `Context.APPLET` environment property obsolete and to be ign
On Tue, 3 Dec 2024 17:36:35 GMT, Aleksei Efimov wrote:
> JNDI dependency on the `java.applet.Applet` has been removed in JDK9 with
> [JDK-8051422](https://bugs.openjdk.org/browse/JDK-8051422). It made the
> `Context.APPLET` environment property obsolete and to be ign
JNDI dependency on the `java.applet.Applet` has been removed in JDK9 with
[JDK-8051422](https://bugs.openjdk.org/browse/JDK-8051422). It made the
`Context.APPLET` environment property obsolete and to be ignored when
`javax.naming.InitialContext` is created.
The proposed change removes `javax.na
On Thu, 28 Nov 2024 00:17:43 GMT, Aleksei Efimov wrote:
> The proposed change cleans-up `SecurityManager`, `doPriviledged`, and
> `AccessController` usages from `java.naming`, `jdk.naming.rmi` and
> `jdk.naming.dns` modules.
>
> One noteworthy change: The `java.naming.rmi.s
ed no failures related
> to this change.
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
Remove SecurityConstants.GET_CLASSLOADER_PERMISSION
-
Changes:
- all: https://git.openjdk.org/jdk/pull/22421/files
- new: ht
On Thu, 28 Nov 2024 17:03:13 GMT, Alan Bateman wrote:
> Sean has hollowed out SecurityConstants in pull/22418 but had to leave
> GET_CLASSLOADER_PERMISSION because of this usage. There will be many rounds
> of cleanup so doesn't matter if it comes later. ALL_PERMISSION will probably
> be the l
On Thu, 28 Nov 2024 07:52:14 GMT, Alan Bateman wrote:
> Good cleanup. Maybe for a follow on PR but I assume VersionHelper can be
> removed. There's been several post JEP 486 removals that mean that
> createThread and loadClass shouldn't be needed now. Also isSerialDataAllowed
> could move to O
ed no failures related
> to this change.
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
Remove com.sun.jndi.ldap.VersionHelper
-
Changes:
- all: https://git.openjdk.org/jdk/pull/22421/files
- new: https://git.openj
The proposed change cleans-up `SecurityManager`, `doPriviledged`, and
`AccessController` usages from `java.naming`, `jdk.naming.rmi` and
`jdk.naming.dns` modules.
One noteworthy change: The `java.naming.rmi.security.manager` JNDI environment
property can be used to setup the `SecurityManager`:
On Fri, 22 Nov 2024 07:06:06 GMT, Alan Bateman wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update with changes from code review.
>
> src/java.rmi/share/classes/sun/rmi/runtime/NewThreadAction.java line 30:
>
>
On Fri, 15 Nov 2024 17:03:50 GMT, Aleksei Efimov wrote:
> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI
> JDK providers, and contains the following changes:
> - The following two properties are removed:
> - `com.sun.jndi.ldap.object.trus
On Wed, 20 Nov 2024 16:31:44 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> change jdk.naming.rmi per Daniel's suggestion
>
> src/jdk.naming.rmi/sha
gistry/objects/ObjectFactoryBuilderCodebaseTest.java`
> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with
> the proposed changes.
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
change
On Wed, 20 Nov 2024 14:13:59 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Docs and comments update
>> - Revert VersionHelper.createThread removal
>
&
On Tue, 19 Nov 2024 20:42:04 GMT, Roger Riggs wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> clarify factory location usages in NamingManager and jdk.naming.rmi
>> module-info
>
On Wed, 20 Nov 2024 11:33:19 GMT, Daniel Fuchs wrote:
>> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 262:
>>
>>> 260: }
>>> 261:
>>> 262: worker = new Thread(this);
>>
>> Rataining a static factory for thread may use useful to be able to customize
>> t
gistry/objects/ObjectFactoryBuilderCodebaseTest.java`
> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with
> the proposed changes.
Aleksei Efimov has updated the pull request incrementally with two additional
commits since the last revision:
- Docs and commen
gistry/objects/ObjectFactoryBuilderCodebaseTest.java`
> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with
> the proposed changes.
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
cl
gistry/objects/ObjectFactoryBuilderCodebaseTest.java`
> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with
> the proposed changes.
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
Implement Daniel sug
On Fri, 15 Nov 2024 01:12:34 GMT, Stuart Marks wrote:
> First cut at removal of Security Manager stuff from RMI.
>
> This covers just about every SM-related case in RMI, except for a bit of
> package checking in MarshalInputStream. This will be handled separately. It's
> covered by [JDK-834432
On Mon, 18 Nov 2024 17:55:31 GMT, Aleksei Efimov wrote:
>> First cut at removal of Security Manager stuff from RMI.
>>
>> This covers just about every SM-related case in RMI, except for a bit of
>> package checking in MarshalInputStream. This will be handled separat
On Fri, 15 Nov 2024 01:12:34 GMT, Stuart Marks wrote:
> First cut at removal of Security Manager stuff from RMI.
>
> This covers just about every SM-related case in RMI, except for a bit of
> package checking in MarshalInputStream. This will be handled separately. It's
> covered by [JDK-834432
This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI
JDK providers, and contains the following changes:
- The following two properties are removed:
- `com.sun.jndi.ldap.object.trustURLCodebase`
- `com.sun.jndi.rmi.object.trustURLCodebase`
- JNDIs object factories l
On Tue, 5 Nov 2024 12:49:04 GMT, Andrey Turbanov wrote:
> Content of Hashtable `com.sun.jndi.ldap.LdapClient#defaultBinaryAttrs` is
> fully initialized in `` block.
> It means we can replace legacy synchronized `Hashtable` with immutable set.
The changes look good to me. Also, I've launched exi
On Fri, 6 Sep 2024 16:28:36 GMT, Aleksei Efimov wrote:
> This PR proposes the following changes to address wrong timeout computations
> in the `com.sun.jndi.dns.DnsClient`:
> - The `DnsClient` has been updated to use a monotonic high-resolution (nano)
> clock. The existing `Timeo
On Mon, 7 Oct 2024 09:00:28 GMT, Aleksei Efimov wrote:
>> This PR proposes the following changes to address wrong timeout computations
>> in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano)
>> clock. The
been executed multiple times (500+) to check if the
> new and the modified tests are stable. No failures been observed (so far?).
Aleksei Efimov has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by t
On Wed, 2 Oct 2024 13:38:17 GMT, Aleksei Efimov wrote:
>> This PR proposes the following changes to address wrong timeout computations
>> in the `com.sun.jndi.dns.DnsClient`:
>> - The `DnsClient` has been updated to use a monotonic high-resolution (nano)
>> clock. The
been executed multiple times (500+) to check if the
> new and the modified tests are stable. No failures been observed (so far?).
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
improve reporting for unrecoverable exceptions
---
been executed multiple times (500+) to check if the
> new and the modified tests are stable. No failures been observed (so far?).
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
Add comment suggested by Daniel
-
Change
On Mon, 30 Sep 2024 13:38:48 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Track unfulfilled timeouts during UDP queries.
>> Update exceptions handling.
>
On Mon, 30 Sep 2024 20:30:57 GMT, Mark Sheppard wrote:
> I think that if there is a PortUnreachable thrown, during DnsClient.query
> processing from the doUdpQuery, then the timeout may expire early ... if I've
> interpreted the outer loop processing correctly
The `DnsClient.query` marks serve
been executed multiple times (500+) to check if the
> new and the modified tests are stable. No failures been observed (so far?).
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
Track unfulfilled timeouts duri
On Wed, 11 Sep 2024 16:27:29 GMT, Daniel Fuchs wrote:
>> 2 time is not too high,
>> I have presented, in the comment, a failures with the elapsed time is almost
>> twice the expected time
>> where the elapsed time is 14229 !! which is approx 1.84 * expected timeout
>
> @msheppar with the latest
On Tue, 10 Sep 2024 19:01:54 GMT, Mark Sheppard wrote:
>> I agree that we don't want to document too much here. Updated the factor to
>> 1.75 (2 seems a bit high and might hide real issues), and to make the
>> timeout value calculation and check less arcane - I have updated test output
>> to p
been executed multiple times (500+) to check if the
> new and the modified tests are stable. No failures been observed (so far?).
Aleksei Efimov has updated the pull request incrementally with two additional
commits since the last revision:
- set min timeout to 0; set max al
On Tue, 10 Sep 2024 14:47:26 GMT, Daniel Fuchs wrote:
>> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 443:
>>
>>> 441: // integer overflow (timeout is an int).
>>> 442: // no point in supporting timeout > Integer.MAX_VALUE,
>>> clamp if n
On Tue, 10 Sep 2024 18:15:34 GMT, Mark Sheppard wrote:
>> I don't think it is a rabbit hole, to provide some additional clarity on the
>> timeout mechanism and to avoid any perception that it has absolute realtime
>> timeout semantics, such that developers have precise view of how the
>> mecha
On Tue, 10 Sep 2024 14:54:58 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Measure time the caller spent waiting. Simplify timeoutLeft computation
>
> src/jdk.na
On Tue, 10 Sep 2024 17:54:30 GMT, Mark Sheppard wrote:
>> If I'm not mistaken here it's `Math.clamp(long, long, long)` which is
>> called - because `timeout * (1L << retry)` is a long. We could make it more
>> obvious by using `0L` instead of `0` too.
>
> thanks for the clarification ... yes i
been executed multiple times (500+) to check if the
> new and the modified tests are stable. No failures been observed (so far?).
Aleksei Efimov has updated the pull request incrementally with three additional
commits since the last revision:
- update tests to calculate allowed timeout range
On Mon, 9 Sep 2024 17:15:43 GMT, Aleksei Efimov wrote:
>> I have been wondering why the timeout was measured in this way. My
>> explanation was that the original author of the API (duke? ;-) ) wanted to
>> measure "actual timeout" (time actually spent waiting for
been executed multiple times (500+) to check if the
> new and the modified tests are stable. No failures been observed (so far?).
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
Measure time the caller spent waiting. Simplify timeout
On Mon, 9 Sep 2024 15:03:46 GMT, Daniel Fuchs wrote:
>> Sounds like a right thing to do: measuring time in the loop should give us
>> better estimation on time DNS client spends waiting on the response after
>> submiting a query (that's how environment property value is defined in
>> [javadoc
been executed multiple times (500+) to check if the
> new and the modified tests are stable. No failures been observed (so far?).
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
fix trailing white-space in a comment
---
been executed multiple times (500+) to check if the
> new and the modified tests are stable. No failures been observed (so far?).
Aleksei Efimov has updated the pull request incrementally with two additional
commits since the last revision:
- Update src/jdk.naming.dns/share
On Mon, 9 Sep 2024 13:58:51 GMT, Daniel Jeliński wrote:
>> Aleksei Efimov has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - guard against possible integer value overflows
>> - make startTime a local v
On Fri, 6 Sep 2024 16:58:20 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - guard against possible integer value overflows
>> - make startTime a local variable
On Sat, 7 Sep 2024 13:12:23 GMT, Jaikiran Pai wrote:
>> Aleksei Efimov has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - guard against possible integer value overflows
>> - make startTime a local variabl
been executed multiple times (500+) to check if the
> new and the modified tests are stable. No failures been observed (so far?).
Aleksei Efimov has updated the pull request incrementally with two additional
commits since the last revision:
- guard against possible integer value overflows
-
This PR proposes the following changes to address wrong timeout computations in
the `com.sun.jndi.dns.DnsClient`:
- The `DnsClient` has been updated to use a monotonic high-resolution (nano)
clock. The existing `Timeout` test has also been updated to use the nano clock
to measure observed timeou
Thank you, Marko - it's an excellent catch! Indeed, we have a bug in a code
that updates the left timeout. And yes, we should use nanoTime for measuring
elapsed time. I will work on a fix for both issues and will try to create a
test for the left timeout update scenario.
- Aleksei
_
On Tue, 2 Jul 2024 16:24:49 GMT, Nizar Benalla wrote:
>> Can I please get a review for this small change? The motivation is that
>> javac does not recognize `package.html` files.
>>
>> The conversion was simple, I used a script to rename the files, append "*"
>> on the left and remove some HTM
On Fri, 28 Jun 2024 10:44:05 GMT, Nizar Benalla wrote:
>> Can I please get a review for this small change? The motivation is that
>> javac does not recognize `package.html` files.
>>
>> The conversion was simple, I used a script to rename the files, append "*"
>> on the left and remove some HT
On Wed, 26 Jun 2024 20:41:56 GMT, Jonathan Gibbons wrote:
>> src/java.naming/share/classes/javax/naming/ldap/package-info.java line 200:
>>
>>> 198: * if (respCtls != null) {
>>> 199: * // Find the one we want
>>> 200: * for (int i = 0; i < respCtls.length; i++) {
>>
>> This is the o
On Wed, 26 Jun 2024 18:11:45 GMT, Nizar Benalla wrote:
>> Can I please get a review for this small change? The motivation is that
>> javac does not recognize `package.html` files.
>>
>> The conversion was simple, I used a script to rename the files, append "*"
>> on the left and remove some HT
On Wed, 20 Mar 2024 21:19:38 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>> com.sun.jndi.ldap.Connection::createS
On Thu, 14 Mar 2024 21:59:54 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>> com.sun.jndi.ldap.Connection::createS
On Fri, 1 Mar 2024 10:44:14 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>> com.sun.jndi.ldap.Connection::createSo
On Fri, 23 Feb 2024 15:30:09 GMT, Aleksei Efimov wrote:
> Thanks for exploring the possibility of improving tracebility of test
> invocations to reported bugs.
>
> >
I've given this test change a second thought, maybe you can try to separate the
test into two separa
On Thu, 22 Feb 2024 11:38:19 GMT, Christoph Langer wrote:
> As for the test, I had a closer look now and I find it hard to separate
> testing of [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) from
> [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579). Furthermore, most
> of
On Tue, 20 Feb 2024 10:28:37 GMT, Christoph Langer wrote:
> Hm, I think the test was overpurposed already.
This test was added by JDK-8314063 fix, and I do not think it was change after
that.
> Creating another test file with duplicating code does not sound too good
> IMHO. Maybe it is acc
On Fri, 16 Feb 2024 10:27:11 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>> com.sun.jndi.ldap.Connection::createS
On Fri, 16 Feb 2024 10:27:11 GMT, Christoph Langer wrote:
>> During analysing a customer case I figured out that we have an inconsistency
>> between documentation and actual behavior in class
>> com.sun.jndi.ldap.Connection. The [method documentation of
>> com.sun.jndi.ldap.Connection::createS
On Fri, 9 Feb 2024 21:29:28 GMT, Christoph Langer wrote:
> During analysing a customer case I figured out that we have an inconsistency
> between documentation and actual behavior in class
> com.sun.jndi.ldap.Connection. The [method documentation of
> com.sun.jndi.ldap.Connection::createSocket
On Thu, 31 Aug 2023 22:48:30 GMT, Aleksei Efimov wrote:
> The change proposed in this PR improves the behavior of the JDK JNDI/LDAP
> provider when running in a virtual thread. Currently, when an LDAP operation
> is performed from a virtual thread context a pinned carrier thread is
&
On Fri, 8 Sep 2023 14:59:38 GMT, Daniel Fuchs wrote:
> Look reasonable to me. If tier2 and all jndi tests are still passing, I'm
> good with it.
Thanks for the review Daniel. `tier1`, `tier2`, `tier3` and JNDI/LDAP JCK tests
showed no failures with the change proposed here.
-
PR
P operations.
>
> Testing: `jdk-tier1` to `jdk-tier3`, other `jndi/ldap` regression and JCK
> naming tests show no failures.
Aleksei Efimov has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by
The change proposed in this PR improves the behavior of the JDK JNDI/LDAP
provider when running in a virtual thread. Currently, when an LDAP operation is
performed from a virtual thread context a pinned carrier thread is detected:
Thread[#29,ForkJoinPool-1-worker-1,5,CarrierThreads]
On Thu, 24 Aug 2023 23:08:43 GMT, Weibing Xiao wrote:
>> Please refer to JDK-8314063.
>>
>> The failure scenario is due to the setting of connection timeout. It is
>> either too small or not an optimal value for the system. When the client
>> tries to connect to the server with LDAPs protocol.
On Thu, 24 Aug 2023 00:10:54 GMT, Weibing Xiao wrote:
>> Please refer to JDK-8314063.
>>
>> The failure scenario is due to the setting of connection timeout. It is
>> either too small or not an optimal value for the system. When the client
>> tries to connect to the server with LDAPs protocol.
On Tue, 22 Aug 2023 18:21:17 GMT, Weibing Xiao wrote:
>> Please refer to JDK-8314063.
>>
>> The failure scenario is due to the setting of connection timeout. It is
>> either too small or not an optimal value for the system. When the client
>> tries to connect to the server with LDAPs protocol.
On Mon, 21 Aug 2023 22:10:06 GMT, Weibing Xiao wrote:
>> Please refer to JDK-8314063.
>>
>> The failure scenario is due to the setting of connection timeout. It is
>> either too small or not an optimal value for the system. When the client
>> tries to connect to the server with LDAPs protocol.
On Sat, 19 Aug 2023 02:15:06 GMT, Weibing Xiao wrote:
>> Please refer to JDK-8314063.
>>
>> The failure scenario is due to the setting of connection timeout. It is
>> either too small or not an optimal value for the system. When the client
>> tries to connect to the server with LDAPs protocol.
On Sat, 19 Aug 2023 02:15:06 GMT, Weibing Xiao wrote:
>> Please refer to JDK-8314063.
>>
>> The failure scenario is due to the setting of connection timeout. It is
>> either too small or not an optimal value for the system. When the client
>> tries to connect to the server with LDAPs protocol.
On Fri, 18 Aug 2023 13:30:54 GMT, Weibing Xiao wrote:
>> Please refer to JDK-8314063.
>>
>> The failure scenario is due to the setting of connection timeout. It is
>> either too small or not an optimal value for the system. When the client
>> tries to connect to the server with LDAPs protocol.
On Wed, 16 Aug 2023 22:57:55 GMT, Mark Sheppard wrote:
>> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 369:
>>
>>> 367: }
>>> 368: }
>>> 369: } catch (Exception e) {
>>
>> The code wrapped in this try-catch block can throw unchecked ex
On Tue, 15 Aug 2023 17:30:54 GMT, Weibing Xiao wrote:
> Please refer to JDK-8314063.
>
> The failure scenario is due to the setting of connection timeout. It is
> either too small or not an optimal value for the system. When the client
> tries to connect to the server with LDAPs protocol. It r
On Mon, 14 Aug 2023 13:27:05 GMT, Weibing Xiao wrote:
>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if
>> the is an IOException generation when the output stream was flushing the
>> buffer.
>>
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657
On Wed, 9 Aug 2023 12:52:35 GMT, Weibing Xiao wrote:
>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if
>> the is an IOException generation when the output stream was flushing the
>> buffer.
>>
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
On Thu, 3 Aug 2023 17:32:43 GMT, Weibing Xiao wrote:
> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if
> the is an IOException generation when the output stream was flushing the
> buffer.
>
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
src
On Fri, 5 May 2023 17:25:38 GMT, Aleksei Efimov wrote:
> JNDI `DnsClient` has a finalize method to close its internal datagram channel
> selector.
> The change proposed here replaces it with a cleaner to close the selector
> once the `DnsClient`
> instance becomes ph
` to `jdk-tier3` test sets which showed
> no failures.
Aleksei Efimov has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains four additional
commits
` to `jdk-tier3` test sets which showed
> no failures.
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
Use cleanable to close the selector in DnsClient::close
-
Changes:
- all: https://git.openjdk.org/jdk/pull/13
On Sat, 6 May 2023 12:47:21 GMT, Alan Bateman wrote:
>> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 165:
>>
>>> 163: // when this DNS client becomes phantom reachable
>>> 164: Selector sel = udpChannelSelector;
>>> 165: CleanerFactory.cleaner().r
` to `jdk-tier3` test sets which showed
> no failures.
Aleksei Efimov has updated the pull request incrementally with one additional
commit since the last revision:
fix comment
-
Changes:
- all: https://git.openjdk.org/jdk/pull/13837/files
- new: https://git.openjdk.
On Fri, 5 May 2023 18:13:29 GMT, Alan Bateman wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fix comment
>
> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsC
JNDI `DnsClient` has a finalize method to close its internal datagram channel
selector.
The change proposed here replaces it with a cleaner to close the selector once
the `DnsClient`
instance becomes phantom reachable.
The change was tested with `jdk-tier1` to `jdk-tier3` test sets which sho
On Tue, 31 Jan 2023 16:19:34 GMT, Aleksei Efimov wrote:
> The proposed change adds a new exception handler method to the
> `test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java` LDAP test library class.
> It will allow LDAP tests to customize the handling of server-side exceptions.
&
On Tue, 31 Jan 2023 16:19:34 GMT, Aleksei Efimov wrote:
> The proposed change adds a new exception handler method to the
> `test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java` LDAP test library class.
> It will allow LDAP tests to customize the handling of server-side exceptions.
&
The proposed change adds a new exception handler method to the
`test/jdk/com/sun/jndi/ldap/lib/BaseLdapServer.java` LDAP test library class.
It will allow LDAP tests to customize the handling of server-side exceptions.
The current `BaseLdapTestServer` implementation prints an exception and its
On Sun, 6 Nov 2022 16:39:48 GMT, Aleksei Efimov wrote:
> ### The Proposed Change
>
> The proposed change updates JNDI's `DnsClient` internal implementation to use
> `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS).
> The main motivation behind this change
entContext.p_lookup(ComponentContext.java:542)
>
> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177)
>
> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166)
> java.naming/javax.nami
On Mon, 7 Nov 2022 20:39:27 GMT, Daniel Fuchs wrote:
>> Thanks for spotting that, Jai.
>> You're correct that in its current version the fix changed an old logic of
>> `doUdpQuery`/`query` methods:
>> Before this change the method was returning `null` not when a receive is
>> timed out but when
On Mon, 7 Nov 2022 20:26:54 GMT, Daniel Fuchs wrote:
>> Aleksei Efimov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments
>
> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DNSDatag
entContext.p_lookup(ComponentContext.java:542)
>
> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177)
>
> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166)
> java.naming/javax.nami
On Mon, 7 Nov 2022 15:41:40 GMT, Aleksei Efimov wrote:
>> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 185:
>>
>>> 183: public void close() {
>>> 184: try {
>>> 185: udpChannelSelector.close();
>>
>
On Mon, 7 Nov 2022 07:13:04 GMT, Jaikiran Pai wrote:
>> ### The Proposed Change
>>
>> The proposed change updates JNDI's `DnsClient` internal implementation to
>> use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS).
>> The main motivation behind this change is to make JNDI/DNS
### The Proposed Change
The proposed change updates JNDI's `DnsClient` internal implementation to use
`DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS).
The main motivation behind this change is to make JNDI/DNS lookups friendly to
virtual-thread environments and update its under
1 - 100 of 132 matches
Mail list logo
