On Tue, 9 Sep 2025 15:03:15 GMT, Daniel Fuchs wrote:
> Hi,
>
> This is a documentation change only. The specification of
> `InterfaceAddress:getBroadcast()` should not say anything specific about the
> loopback interface as it appears that on some systems a broadcast address can
> be configu
On Tue, 1 Jul 2025 11:25:32 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test-only change which addresses an
>> intermittent failure in `test/jdk/com/sun/net/httpserver/Test12.java`? This
>> fixes https://bugs.openjdk.org/browse/JDK-8359477.
>>
>> In the linked JBS issue I've
On Fri, 13 Jun 2025 16:08:43 GMT, Daniel Fuchs wrote:
>> why are you insisting on specifying 60 seconds? It does not exist on any
>> supported OS platform. There is no need to specify any value in the apiNote,
>> all it does is add misinformation
>
> Maybe we could say:
>
>
> The typical oper
On Fri, 13 Jun 2025 14:36:21 GMT, Alan Bateman wrote:
>> "The timeout values noted in that text are mere examples to convey the
>> detail that application developers need to be aware that the timeout they
>> pass to the connect() method may not influence connection establishment
>> failure due
On Fri, 13 Jun 2025 13:49:55 GMT, Jaikiran Pai wrote:
>The timeout values noted in that text are mere examples to convey the detail
>that application developers need to >be aware that the timeout they pass to
>the connect() method may not influence connection establishment failure >due
>to tim
On Fri, 13 Jun 2025 07:08:58 GMT, Jaikiran Pai wrote:
>> FWIW an possible alternative wording
>>
>> Establishing a TCP/IP connection is subject to a connect timeout, determined
>> by configuration settings
>> of the operating system, for example the number of connect retries together
>> with a
On Wed, 11 Jun 2025 21:16:40 GMT, Mark Sheppard wrote:
>>> Alan @AlanBateman, do you suggest we continue with this text or would any
>>> update be necessary?
>>
>> I think it's helpful here to give some indication in this API note as what
>> the time
On Wed, 11 Jun 2025 12:38:43 GMT, Alan Bateman wrote:
>> I think it is an unnecessary quantification, is somewhat inaccurate, and set
>> an expectation of a developer that this is gospel or axiomatic. Indicating
>> that it is OS dependent should be sufficient.
>
>> Alan @AlanBateman, do you su
On Wed, 11 Jun 2025 11:47:36 GMT, Jaikiran Pai wrote:
>> FWIW:
>> Stating a typical value of 60 seconds timeout can lead to a misconception or
>> set an expectation ... From from TCP standards and depending on which
>> literature you read (OS docs or unix networking socket programming) then 75
On Mon, 9 Jun 2025 11:40:37 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/java/net/Socket.java line 625:
>>
>>> 623: *
>>> 624: * @apiNote Establishing a TCP/IP connection is subject to
>>> connection timeout settings
>>> 625: * in the operating system. The typical time
On Wed, 28 May 2025 11:13:12 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Tue, 27 May 2025 13:25:38 GMT, Mikhail Yankelevich
wrote:
>> HttpServer::stop will terminate the server immidiately after all exhcnages
>> are complete.
>> If the exchanges take longer then the specified delay it will terminate
>> straight after the delay, the same as the previous behaviour
On Mon, 26 May 2025 19:22:39 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/jdk/internal/util/Exceptions.java line 253:
>>
>>> 251: return;
>>> 252: enhancedSocketExceptionText =
>>> SecurityProperties.includedInExceptions("hostInfo");
>>> 253: enhancedNonSo
On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Mon, 26 May 2025 10:31:39 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
On Fri, 23 May 2025 09:57:02 GMT, Daniel Fuchs wrote:
> > If I have read the original code correctly there is a flaw in it, that is
> > the startExchange is never called.
>
> @msheppar what do you mean by that? It's called in
> [ExchangeImpl.java](https://github.com/openjdk/jdk/blob/68ee06f0c9
On Fri, 23 May 2025 08:54:42 GMT, Mikhail Yankelevich
wrote:
>> src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java line 227:
>>
>>> 225: }
>>> 226:
>>> 227: public final boolean isFinishing() {
>>
>> encapsulating the server state in a CountDownLatch is obfuscated sem
On Thu, 22 May 2025 12:27:46 GMT, Mikhail Yankelevich
wrote:
>> HttpServer::stop will terminate the server immidiately after all exhcnages
>> are complete.
>> If the exchanges take longer then the specified delay it will terminate
>> straight after the delay, the same as the previous behaviour
On Thu, 22 May 2025 12:27:46 GMT, Mikhail Yankelevich
wrote:
>> HttpServer::stop will terminate the server immidiately after all exhcnages
>> are complete.
>> If the exchanges take longer then the specified delay it will terminate
>> straight after the delay, the same as the previous behaviour
On Thu, 22 May 2025 12:27:46 GMT, Mikhail Yankelevich
wrote:
>> HttpServer::stop will terminate the server immidiately after all exhcnages
>> are complete.
>> If the exchanges take longer then the specified delay it will terminate
>> straight after the delay, the same as the previous behaviour
On Tue, 25 Mar 2025 20:49:20 GMT, Chen Liang wrote:
>> Volkan Yazici has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Add more tests
>> - Guard vectorization better
>> - Restore the old garbage-free state
>
> src/java.net.http/share
On Mon, 17 Mar 2025 08:05:54 GMT, Volkan Yazici wrote:
>> persisting with method nomenclature (or painting the bikeshed again). What’s
>> in a name?
>>
>> reset is really init() or setMask()
>>
>> Currently you have a static applyMask() method and a non static
>> applyMask() — is that
On Fri, 14 Mar 2025 10:11:29 GMT, Volkan Yazici wrote:
>> Fixes endian handling `jdk.internal.net.http.websocket.Frame.Masker`.
>>
>> ### Implementation notes
>>
>> I deleted the `Frame` clone in tests, and rewired the test code depending on
>> it to the actual `Frame`. To enable this, I relax
On Thu, 13 Mar 2025 13:42:40 GMT, Volkan Yazici wrote:
>> Fixes endian handling `jdk.internal.net.http.websocket.Frame.Masker`.
>>
>> ### Implementation notes
>>
>> I deleted the `Frame` clone in tests, and rewired the test code depending on
>> it to the actual `Frame`. To enable this, I relax
On Thu, 13 Mar 2025 18:10:53 GMT, Daniel Fuchs wrote:
>> Volkan Yazici has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix copyright years
>
> src/java.net.http/share/classes/jdk/internal/net/http/websocket/Frame.java
> line 105:
>
>>
On Tue, 4 Mar 2025 12:18:10 GMT, serhiysachkov wrote:
>> switching to nanoTime as suggested in ticket comments
>
> serhiysachkov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8281511: update check timeout logic to take into account lower
On Fri, 28 Feb 2025 14:40:28 GMT, serhiysachkov wrote:
>> switching to nanoTime as suggested in ticket comments
>
> serhiysachkov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8281511: update Copyright header
I think the checkTime from t
On Fri, 28 Feb 2025 13:35:14 GMT, serhiysachkov wrote:
>> switching to nanoTime as suggested in ticket comments
>
> serhiysachkov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8281511: java/net/ipv6tests/UdpTest.java fails with checkTime
On Mon, 6 Jan 2025 05:43:31 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address the
> test-only issue noted in https://bugs.openjdk.org/browse/JDK-8347000?
>
> As noted in that issue, the test issues HTTP requests with `Content-Length`
> set to `0` imp
On Mon, 6 Jan 2025 05:43:31 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address the
> test-only issue noted in https://bugs.openjdk.org/browse/JDK-8347000?
>
> As noted in that issue, the test issues HTTP requests with `Content-Length`
> set to `0` imp
I think there is a misinterpretation of the HTTP spec here.
A server is not a User Agent.
The GET request is delimited by the Content-Length: 0 and the two blank line
( ) , such that a server would not look for a request body
For the request in the test, anything after the blanks line are ignore
On Fri, 22 Nov 2024 09:32:43 GMT, Volkan Yazıcı wrote:
>> This PR, addressing 8343791, changes `Socket::connect()` methods to close
>> the `Socket` in the event that the connection cannot be established, the
>> timeout expires before the connection is established, or the socket address
>> is u
On Fri, 22 Nov 2024 09:32:43 GMT, Volkan Yazıcı wrote:
>> This PR, addressing 8343791, changes `Socket::connect()` methods to close
>> the `Socket` in the event that the connection cannot be established, the
>> timeout expires before the connection is established, or the socket address
>> is u
On Fri, 22 Nov 2024 09:32:43 GMT, Volkan Yazıcı wrote:
>> This PR, addressing 8343791, changes `Socket::connect()` methods to close
>> the `Socket` in the event that the connection cannot be established, the
>> timeout expires before the connection is established, or the socket address
>> is u
On Thu, 21 Nov 2024 10:47:54 GMT, Volkan Yazıcı wrote:
>> This PR, addressing 8343791, changes `Socket::connect()` methods to close
>> the `Socket` in the event that the connection cannot be established, the
>> timeout expires before the connection is established, or the socket address
>> is u
On Thu, 21 Nov 2024 10:47:54 GMT, Volkan Yazıcı wrote:
>> This PR, addressing 8343791, changes `Socket::connect()` methods to close
>> the `Socket` in the event that the connection cannot be established, the
>> timeout expires before the connection is established, or the socket address
>> is u
On Thu, 21 Nov 2024 10:47:54 GMT, Volkan Yazıcı wrote:
>> This PR, addressing 8343791, changes `Socket::connect()` methods to close
>> the `Socket` in the event that the connection cannot be established, the
>> timeout expires before the connection is established, or the socket address
>> is u
On Thu, 14 Nov 2024 12:42:44 GMT, Jaikiran Pai wrote:
> Hello Mark,
>
> > is it the case that a try-with-resource, and the implicit final declaration
> > of s2, will maintain a strongly reachable reference ?
> > Rather than having to declare s2 as a final member variable of
> > Socket_getInput
On Thu, 14 Nov 2024 12:39:39 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this test-only fix which addresses the
>> intermittent failure in AsyncClose test as noted in
>> https://bugs.openjdk.org/browse/JDK-8343877?
>>
>> The `FileDescriptor` of the `Socket` instance that gets retu
On Thu, 14 Nov 2024 04:56:12 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only fix which addresses the
> intermittent failure in AsyncClose test as noted in
> https://bugs.openjdk.org/browse/JDK-8343877?
>
> The `FileDescriptor` of the `Socket` instance that gets returned
On Mon, 9 Sep 2024 10:01:40 GMT, Daniel Fuchs wrote:
>> Please find here a change that adds a few `@apiNote` and `@implNote` to
>> `NetworkInterface` to clarify user expectation and implementation.
>
> Daniel Fuchs has updated the pull request incrementally with one additional
> commit since th
On Fri, 6 Sep 2024 11:55:08 GMT, Daniel Fuchs wrote:
>> Please find here a change that adds a few `@apiNote` and `@implNote` to
>> `NetworkInterface` to clarify user expectation and implementation.
>
> Daniel Fuchs has updated the pull request incrementally with one additional
> commit since th
On Tue, 3 Sep 2024 13:54:44 GMT, Daniel Fuchs wrote:
>> Please find here a change that adds a few `@apiNote` and `@implNote` to
>> `NetworkInterface` to clarify user expectation and implementation.
>
> Daniel Fuchs has updated the pull request with a new target base due to a
> merge or a rebase
On Mon, 2 Sep 2024 13:48:55 GMT, Daniel Fuchs wrote:
> Please find here a change that adds a few `@apiNote` and `@implNote` to
> `NetworkInterface` to clarify user expectation and implementation.
Also, I think it would be useful and helpful to allude to the "snapshot"
characteristics of a Netw
On Wed, 1 May 2024 20:42:22 GMT, robert engels wrote:
> But on the point above is not correct. If you follow the code path, you will
> see that setting a length of 0 - which is what that method defers to - will
> cause a chunked response to be sent - when it is written to the OutputStream.
> I
On Fri, 26 Apr 2024 15:37:13 GMT, robert engels wrote:
>> improve the HttpExchange api with documented constants and convenience
>> methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
> sr
On Fri, 26 Apr 2024 15:37:13 GMT, robert engels wrote:
>> improve the HttpExchange api with documented constants and convenience
>> methods to avoid common bugs
>
> robert engels has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update
> sr
On Wed, 6 Dec 2023 16:33:40 GMT, Mark Sheppard wrote:
> Test java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java fails
> fails due to dynamic reconfigurations of network interface during test - this
> fix uses the utility method NetworkConfiguration::isSameInterface t
Additionally, for macosx the awdl and
> llw interfaces are excluded from the test
>
> Please oblige and review this change to address issue
> https://bugs.openjdk.org/browse/JDK-8263256
Mark Sheppard has updated the pull request incrementally with one additional
commit since the last re
Additionally, for macosx the awdl and
> llw interfaces are excluded from the test
>
> Please oblige and review this change to address issue
> https://bugs.openjdk.org/browse/JDK-8263256
Mark Sheppard has updated the pull request incrementally with one additional
commit since the last re
Test java/net/Inet6Address/serialize/Inet6AddressSerializationTest.java fails
fails due to dynamic reconfigurations of network interface during test - this
fix uses the utility method NetworkConfiguration::isSameInterface to replace
NetworkInterface::equals method call. Additionally, for macosx
On Tue, 28 Nov 2023 18:59:15 GMT, Alan Bateman wrote:
> > Returns: the local address to which the socket is bound, null if the socket
> > is closed, or an InetAddress representing
> > [wildcard](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/net/InetAddress.html#isAnyLocalAdd
On Tue, 28 Nov 2023 13:48:35 GMT, Alan Bateman wrote:
> > Also, the return for the case of an unbound DatagramSocket or
> > DatagramChannel is not specified.
>
> DatagramChannel::getLocalAddress is specified to return null when channel's
> socket is not bound. DatagramSocket::getLocalSocketAdd
On Tue, 28 Nov 2023 16:43:47 GMT, Michael McMahon wrote:
> That is the behavior for the main supported platforms. We had a concern that
> it might not be the case on other platforms. Hence, the word "may".
yes, appreciate that sentiment, but "may" is a bit flippy floppy - a
definitely maybe.
On Tue, 28 Nov 2023 12:31:22 GMT, Michael McMahon wrote:
>> Hi,
>>
>> This is a small doc change for DatagramChannel.getLocalAddress() and the
>> equivalent methods on DatagramSocket which documents some existing (but not
>> currently documented) behavior.
>>
>> Thanks,
>> Michael
>
> Michael
On Sat, 7 Oct 2023 12:01:25 GMT, Alan Bateman wrote:
> > The functionality can be fully provided by the overloaded (static)
> > getByAddress in the base InetAddress class
>
> I don't think I agree with this. The existing 2-arg getByAddress method takes
> a string that is a host name or string
On Mon, 18 Sep 2023 13:43:47 GMT, Daniel Fuchs wrote:
> The main motivation here is to have a method that will create an InetAddress
> from an IP literal, and throw if the string given as parameters doesn't
> correspond to an IP literal. By comparison, `getByName` will try to parse the
> given
On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov wrote:
> ### Summary
>
> The changes in this PR add new API to `java.net.InetAddress`,
> `java.net.Inet4Address`, and
> `java.net.Inet6Address` classes to parse IP address literals:
> ```
> method public static java.net.InetAddress
> java.net
On Sat, 7 Oct 2023 12:01:25 GMT, Alan Bateman wrote:
> > The functionality can be fully provided by the overloaded (static)
> > getByAddress in the base InetAddress class
>
> I don't think I agree with this. The existing 2-arg getByAddress method takes
> a string that is a host name or string
On Sat, 23 Sep 2023 17:28:55 GMT, Aleksei Efimov wrote:
>> ### Summary
>>
>> The changes in this PR add new API to `java.net.InetAddress`,
>> `java.net.Inet4Address`, and
>> `java.net.Inet6Address` classes to parse IP address literals:
>> ```
>> method public static java.net.InetAddress
>>
On Sat, 23 Sep 2023 17:28:55 GMT, Aleksei Efimov wrote:
>> ### Summary
>>
>> The changes in this PR add new API to `java.net.InetAddress`,
>> `java.net.Inet4Address`, and
>> `java.net.Inet6Address` classes to parse IP address literals:
>> ```
>> method public static java.net.InetAddress
>>
On Mon, 18 Sep 2023 13:43:47 GMT, Daniel Fuchs wrote:
> The main motivation here is to have a method that will create an InetAddress
> from an IP literal, and throw if the string given as parameters doesn't
> correspond to an IP literal. By comparison, `getByName` will try to parse the
> given
On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov wrote:
> ### Summary
>
> The changes in this PR add new API to `java.net.InetAddress`,
> `java.net.Inet4Address`, and
> `java.net.Inet6Address` classes to parse IP address literals:
> ```
> method public static java.net.InetAddress
> java.net
On Sun, 17 Sep 2023 13:38:08 GMT, Aleksei Efimov wrote:
> ### Summary
>
> The changes in this PR add new API to `java.net.InetAddress`,
> `java.net.Inet4Address`, and
> `java.net.Inet6Address` classes to parse IP address literals:
> ```
> method public static java.net.InetAddress
> java.net
On Mon, 24 Jul 2023 08:05:57 GMT, Michael McMahon wrote:
>> Hi,
>>
>> JDK-8236852 was fixed in 15 and included its own regression test, but a
>> couple of existing tests have code commented out that also test this
>> functionality. One scenario relating to sending to the wildcard address was
On Thu, 20 Jul 2023 10:50:17 GMT, Michael McMahon wrote:
> Hi,
>
> JDK-8236852 was fixed in 15 and included its own regression test, but a
> couple of existing tests have code commented out that also test this
> functionality. One scenario relating to sending to the wildcard address was
> not
On Fri, 30 Jun 2023 09:17:42 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> `equals` and `hashCode` for the java.net package.
>
> Note, in NetworkInterface we could do even more and change this:
>
> for (InetAddress thisAddr : thi
On Fri, 30 Jun 2023 09:17:42 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> `equals` and `hashCode` for the java.net package.
>
> Note, in NetworkInterface we could do even more and change this:
>
> for (InetAddress thisAddr : thi
On Fri, 30 Jun 2023 09:17:42 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> `equals` and `hashCode` for the java.net package.
>
> Note, in NetworkInterface we could do even more and change this:
>
> for (InetAddress thisAddr : thi
On Thu, 8 Jun 2023 14:09:01 GMT, Darragh Clarke wrote:
>> `HttpURLConnectionExpectContinueTest` was throwing an error due to port
>> being hardcoded, updated test to let the system decide which port to use.
>
> Darragh Clarke has updated the pull request incrementally with one additional
> comm
On Fri, 26 May 2023 13:34:08 GMT, Daniel Fuchs wrote:
>> `HttpURLConnectionExpectContinueTest` was throwing an error due to port
>> being hardcoded, updated test to let the system decide which port to use.
>
> test/jdk/java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java
> line 7
On Thu, 25 May 2023 07:14:19 GMT, Deepa Kumari wrote:
> DatagramSocket delegates to an inner DatagramSocket object. Irrespective of
> whether datagramSocket is IPv4 or IPv6, we create an IPv6 datagramChannel as
> its's delegate. So, This can cause problems with operations like joinGroup.
>
>
On Tue, 14 Mar 2023 19:41:25 GMT, Daniel Jeliński wrote:
> This change improves the running time of many httpserver tests; it removes
> the one second delay introduced by `delay()` calls, and performs immediate
> httpserver stop by calling `stop(0)`.
>
> For example, `com/sun/net/httpserver/Te
On Thu, 16 Feb 2023 16:49:09 GMT, Rich DiCroce wrote:
>> Improves performance and correctness, as discussed on the net-dev mailing
>> list.
>
> Rich DiCroce has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Limit line length to 80-ish charac
On Thu, 16 Feb 2023 16:49:09 GMT, Rich DiCroce wrote:
>> Improves performance and correctness, as discussed on the net-dev mailing
>> list.
>
> Rich DiCroce has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Limit line length to 80-ish charac
On Tue, 7 Feb 2023 15:40:48 GMT, Darragh Clarke wrote:
>> Currently there is a race condition that can allow for too many
>> 'idleConnections' in `ServerImpl`
>>
>> This PR adds a lock to make sure only one connection can be marked Idle at a
>> time as well as a test that consistently failed b
On Tue, 7 Feb 2023 15:40:48 GMT, Darragh Clarke wrote:
>> Currently there is a race condition that can allow for too many
>> 'idleConnections' in `ServerImpl`
>>
>> This PR adds a lock to make sure only one connection can be marked Idle at a
>> time as well as a test that consistently failed b
On Fri, 30 Sep 2022 11:51:34 GMT, Jaikiran Pai wrote:
>> Good point. The JBS issue should be marked with `noreg-self` too.
>
> Hello Mark, it hasn't always been clear to me when to update the `@bug`. The
> contribution guide isn't completely clear either. So I usually update the bug
> id if the
On Fri, 30 Sep 2022 10:20:50 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this test-only change which proposes to
>> improve the test run duration of `java/net/vthread/HttpALot.java` test, on
>> Linux? This relates to https://bugs.openjdk.org/browse/JDK-8294610
>>
>> Experiments h
On Thu, 30 Jun 2022 16:54:53 GMT, Bill Huang wrote:
>> Failure was observed on
>> java/net/DatagramSocket/InterruptibleDatagramSocket.java where data was
>> received unexpectedly (
>> [JDK-8286607](https://bugs.openjdk.org/browse/JDK-8286607)). This failure
>> could be caused by interference
On Tue, 28 Jun 2022 17:19:32 GMT, Bill Huang wrote:
>> Failure was observed on
>> java/net/DatagramSocket/InterruptibleDatagramSocket.java where data was
>> received unexpectedly (
>> [JDK-8286607](https://bugs.openjdk.org/browse/JDK-8286607)). This failure
>> could be caused by interference
On Tue, 28 Jun 2022 16:54:46 GMT, Bill Huang wrote:
>> test/jdk/java/net/DatagramSocket/InterruptibleDatagramSocket.java line 111:
>>
>>> 109: }
>>> 110: try (DatagramSocket s = DatagramChannel.open().socket()) {
>>> 111: System.out.println("Testing interrrupt of Data
On Mon, 27 Jun 2022 16:16:47 GMT, Bill Huang wrote:
>> Failure was observed on
>> java/net/DatagramSocket/InterruptibleDatagramSocket.java where data was
>> received unexpectedly (
>> [JDK-8286607](https://bugs.openjdk.org/browse/JDK-8286607)). This failure
>> could be caused by interference
On Sat, 25 Jun 2022 05:24:23 GMT, Alan Bateman wrote:
>> Failure was observed on
>> java/net/DatagramSocket/InterruptibleDatagramSocket.java where data was
>> received unexpectedly (
>> [JDK-8286607](https://bugs.openjdk.org/browse/JDK-8286607)). This failure
>> could be caused by interferenc
88 matches
Mail list logo
