On Tue, 2 Sep 2025 06:08:12 GMT, Jaikiran Pai wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace "throw new jtreg.SkippedException" ad "throw new SkippedException"
>
On Tue, 2 Sep 2025 05:54:18 GMT, Jaikiran Pai wrote:
>> The test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java observed
>> intermittent fails. Before the root cause of failure has been fixed, should
>> we mark this test `@key intermittent`, to make some setups skip this test or
>> re-run
On Tue, 2 Sep 2025 06:03:34 GMT, Jaikiran Pai wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace "throw new jtreg.SkippedException" ad "throw new SkippedException"
&g
On Fri, 22 Aug 2025 13:30:19 GMT, SendaoYan wrote:
> Currently, take test/jdk/com/sun/nio/sctp/SctpMultiChannel/Branch.java as
> example. When Util.isSCTPSupported() return false, then test print a warning
> and the exit.
>
> I think it's better to throw jtreg.SkippedE
then report test passed.
>
> Change has been verified locally, test-fix only, almost no risk.
SendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
Remove extra blank line
-
Changes:
- all: https://git.openjdk.org/jdk/pu
then report test passed.
>
> Change has been verified locally, test-fix only, almost no risk.
SendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
Remove unnecessary "import
com.sun.nio.sctp.SctpStandardSocketOptions.InitMaxStreams;
On Sat, 23 Aug 2025 02:46:06 GMT, SendaoYan wrote:
> The test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java observed
> intermittent fails. Before the root cause of failure has been fixed, should
> we mark this test `@key intermittent`, to make some setups skip this test or
>
On Wed, 20 Aug 2025 03:30:26 GMT, SendaoYan wrote:
> The test java/net/httpclient/ManyRequests.java has been observed intermittent
> failure such as https://bugs.openjdk.org/browse/JDK-8327968 and
> https://bugs.openjdk.org/browse/JDK-8365811. Should we mark this test as
> `@
On Wed, 20 Aug 2025 11:51:03 GMT, Jaikiran Pai wrote:
>> The test java/net/httpclient/ManyRequests.java has been observed
>> intermittent failure such as https://bugs.openjdk.org/browse/JDK-8327968 and
>> https://bugs.openjdk.org/browse/JDK-8365811. Should we mark this test as
>> `@intermitten
On Thu, 21 Aug 2025 09:10:26 GMT, Leo Korinth wrote:
>> Yes, this PR change the default timeoutFactor when the tested JVM options do
>> not contains '-Xcomp', and at the same time also multiplies 4 of the timeout
>> value defined in some tests.
>>
>> So after this PR, the tests which the timeo
4, after this PR the new
>> default is 120 * 1
>
> @sendaoYan this PR changes the default timeoutFactor and so also has to
> change quite a number of implicit and explicit timeouts. But that doesn't
> mean that test configs that already set their own timeoutFactor should adjust
&
The test java/net/httpclient/ManyRequests.java has been observed intermittent
failure such as https://bugs.openjdk.org/browse/JDK-8327968 and
https://bugs.openjdk.org/browse/JDK-8365811. Should we mark this test as
`@intermittent`.
-
Commit messages:
- 8365834: Mark java/net/httpc
On Tue, 19 Aug 2025 16:53:45 GMT, Jaikiran Pai wrote:
> Can I please get a review of this trivial test-only fix which addresses the
> failure in `test/jdk/java/net/CookieHandler/B6644726.java`? This addresses
> https://bugs.openjdk.org/browse/JDK-8365811.
>
> The test verifies the behaviour of
t timeout = 120
> * 10 = 1200 but new default = 120 * 2.5 = 300!).
>
> However I see the concern of @sendaoYan because individual tests may now get
> much larger timeout values when run with the non-default timeoutFactor
> because they have been adjusted for the new default. I don
On Mon, 18 Aug 2025 09:15:29 GMT, Leo Korinth wrote:
>> It is unclear to me if the author meant this to be `2.5` more than normal or
>> `10` more than JTREG default, or a `multiplier that seems to work`. It does
>> not bother me _more_ if it is a `10` then a `2.5`, as it needs to have a
>> val
On Fri, 15 Aug 2025 11:43:33 GMT, Leo Korinth wrote:
>> This changes the timeout factor from 4 to 1. Most of the changes add
>> timeouts to individual test cases so that I am able to run them with a
>> timeout factor of 0.7 (some margin to the checked in factor of one)
>>
>> In addition to cha
On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote:
> This changes the timeout factor from 4 to 1. Most of the changes add timeouts
> to individual test cases so that I am able to run them with a timeout factor
> of 0.7 (some margin to the checked in factor of one)
>
> In addition to changing
On Tue, 12 Aug 2025 17:01:41 GMT, Leo Korinth wrote:
> This changes the timeout factor from 4 to 1. Most of the changes add timeouts
> to individual test cases so that I am able to run them with a timeout factor
> of 0.7 (some margin to the checked in factor of one)
>
> In addition to changing
On Thu, 24 Jul 2025 13:02:41 GMT, SendaoYan wrote:
> Hi all,
>
> I think the test java/net/ipv6tests/TcpTest.java should report
> jtreg.SkippedException when there no IPV4 addresses or no IPV6 addresses,
> rather than just print a messge and then report test run passes.
>
On Fri, 25 Jul 2025 07:39:40 GMT, Jaikiran Pai wrote:
>> Hi all,
>>
>> I think the test java/net/ipv6tests/TcpTest.java should report
>> jtreg.SkippedException when there no IPV4 addresses or no IPV6 addresses,
>> rather than just print a messge and then report test run passes.
>>
>> Change h
Test.java line 68:
>
>> 66: checkDebug(args);
>> 67: if (ia4addr == null) {
>> 68: throw new SkippedException("No IPV4 addresses: exiting
>> test");
>
> Hello @sendaoYan, isn't an `import jtreg.SkippedException;` requir
Hi all,
I think the test java/net/ipv6tests/TcpTest.java should report
jtreg.SkippedException when there no IPV4 addresses or no IPV6 addresses,
rather than just print a messge and then report test run passes.
Change has been verified locally, both enable ipv6 and disable ipv6 on linux.
When e
On Fri, 13 Jun 2025 06:36:19 GMT, SendaoYan wrote:
> Hi all,
>
> Test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java should throw
> jtreg.SkippedException when there is no lsof command or there is no SCTP in
> test machine.
> Before this PR, this test report Executi
8466. I think the test failure is
>> unrelated to this PR.
>
> Hello @sendaoYan, thank you for verifying. I have checked in our CI too and
> this test continues to get executed where SCTP is supported and lsof is
> present. That's a good thing. You can go ahead with the inte
On Mon, 16 Jun 2025 16:29:11 GMT, Jaikiran Pai wrote:
>> Hi all,
>>
>> Test com/sun/nio/sctp/SctpChannel/CloseDescriptors.java should throw
>> jtreg.SkippedException when there is no lsof command or there is no SCTP in
>> test machine.
>> Before this PR, this test report Execution successful w
On Thu, 12 Jun 2025 18:52:12 GMT, Daniel Fuchs wrote:
>> Like
>> [java/net/HttpURLConnection/HttpURLConnectionExpectContinueTest.java](https://git.openjdk.org/jdk/pull/25692),
>> the test java/net/URL/EarlyOrDelayedParsing doesn't expect proxies, and may
>> fail if a proxy is selected.
>>
>>
On Wed, 21 May 2025 10:34:09 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test-only change which removes the usage of
> the outdated `jdk.tracePinnedThreads` system property from the httpclient
> tests? This addresses https://bugs.openjdk.org/browse/JDK-8357406.
>
> As noted in
On Thu, 10 Apr 2025 10:38:57 GMT, Volkan Yazici wrote:
> `ServerUdsChannelHolder` is introduced to manage the life cycle of a
> `ServerSocketChannel` created using Unix domain sockets (UDS) in a
> thread-safe manner.
>
> ### Testing
>
> Changes can be tested as follows:
>
>
> make build-mic
On Tue, 4 Mar 2025 18:37:48 GMT, Daniel Fuchs wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update the comment and remove "import jtreg.SkippedException"
>
> test/jdk/java/
.. 301 Moved Permanently
> Location: http://cn.bing.com/ [following]
> --2025-02-24 17:56:25-- http://cn.bing.com/
> Reusing existing connection to 192.168.50.1:10991.
> Proxy request sent, awaiting response... 200 OK
> Length: 13006 (13K) [text/html]
> Saving to: ‘index.html’
>
On Tue, 4 Mar 2025 14:11:17 GMT, Daniel Fuchs wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> revert change of "255.255.255.0"
>
> test/jdk/java/net/InetAddress/IsReachab
.. 301 Moved Permanently
> Location: http://cn.bing.com/ [following]
> --2025-02-24 17:56:25-- http://cn.bing.com/
> Reusing existing connection to 192.168.50.1:10991.
> Proxy request sent, awaiting response... 200 OK
> Length: 13006 (13K) [text/html]
> Saving to: ‘index.html’
>
On Tue, 4 Mar 2025 10:52:18 GMT, Daniel Fuchs wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary Exeception
>
> test/jdk/java/net/InetAddress/getOriginalHostName.java
.. 301 Moved Permanently
> Location: http://cn.bing.com/ [following]
> --2025-02-24 17:56:25-- http://cn.bing.com/
> Reusing existing connection to 192.168.50.1:10991.
> Proxy request sent, awaiting response... 200 OK
> Length: 13006 (13K) [text/html]
> Saving to: ‘index.html’
>
.. 301 Moved Permanently
> Location: http://cn.bing.com/ [following]
> --2025-02-24 17:56:25-- http://cn.bing.com/
> Reusing existing connection to 192.168.50.1:10991.
> Proxy request sent, awaiting response... 200 OK
> Length: 13006 (13K) [text/html]
> Saving to: ‘index.html’
>
On Tue, 4 Mar 2025 10:50:20 GMT, Daniel Fuchs wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary Exeception
>
> test/jdk/java/net/InetAddress/IsReachableViaLoopb
On Mon, 3 Mar 2025 14:35:30 GMT, Daniel Fuchs wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove "@build jtreg.SkippedException"
>
> test/jdk/java/net/InetAddress/ge
.. 301 Moved Permanently
> Location: http://cn.bing.com/ [following]
> --2025-02-24 17:56:25-- http://cn.bing.com/
> Reusing existing connection to 192.168.50.1:10991.
> Proxy request sent, awaiting response... 200 OK
> Length: 13006 (13K) [text/html]
> Saving to: ‘index.html’
>
.. 301 Moved Permanently
> Location: http://cn.bing.com/ [following]
> --2025-02-24 17:56:25-- http://cn.bing.com/
> Reusing existing connection to 192.168.50.1:10991.
> Proxy request sent, awaiting response... 200 OK
> Length: 13006 (13K) [text/html]
> Saving to: ‘index.html’
>
.. 301 Moved Permanently
> Location: http://cn.bing.com/ [following]
> --2025-02-24 17:56:25-- http://cn.bing.com/
> Reusing existing connection to 192.168.50.1:10991.
> Proxy request sent, awaiting response... 200 OK
> Length: 13006 (13K) [text/html]
> Saving to: ‘index.html’
>
.. 301 Moved Permanently
> Location: http://cn.bing.com/ [following]
> --2025-02-24 17:56:25-- http://cn.bing.com/
> Reusing existing connection to 192.168.50.1:10991.
> Proxy request sent, awaiting response... 200 OK
> Length: 13006 (13K) [text/html]
> Saving to: ‘index.html’
>
On Mon, 3 Mar 2025 10:21:08 GMT, Mikhail Yankelevich wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove "@build jtreg.SkippedException"
>
> test/jdk/java/net/InetAddress
On Mon, 3 Mar 2025 10:26:41 GMT, Mikhail Yankelevich wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Replace "import *" as import explicitly
>
> test/jdk/java/net/InetAddress
.. 301 Moved Permanently
> Location: http://cn.bing.com/ [following]
> --2025-02-24 17:56:25-- http://cn.bing.com/
> Reusing existing connection to 192.168.50.1:10991.
> Proxy request sent, awaiting response... 200 OK
> Length: 13006 (13K) [text/html]
> Saving to: ‘index.html’
>
On Mon, 3 Mar 2025 10:40:22 GMT, Mikhail Yankelevich wrote:
>> SendaoYan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> "Network setup issue" more concisely
>
> test/jdk/java/net/InetAddress
.. 301 Moved Permanently
> Location: http://cn.bing.com/ [following]
> --2025-02-24 17:56:25-- http://cn.bing.com/
> Reusing existing connection to 192.168.50.1:10991.
> Proxy request sent, awaiting response... 200 OK
> Length: 13006 (13K) [text/html]
> Saving to: ‘index.html’
>
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 Fri, 23 Aug 2024 06:23:28 GMT, Jaikiran Pai wrote:
> Thank you for running those tests. I ran tier1, tier2 and tier3 in our CI too
> with these changes and it looks fine. I'll go ahead and sponsor this now.
Thanks for the verified and sponsor.
-
PR Comment: https://git.openjdk.
On Wed, 21 Aug 2024 03:45:24 GMT, SendaoYan wrote:
> Hi,
> On linux test environments which has docker service, `ifconfig` shows that
> `docker0` appears to be a virtual ethernet bridge which is created by the
> docker host. And the `docker0` virtual ethernet bridge may cause test
On Wed, 21 Aug 2024 12:45:22 GMT, SendaoYan wrote:
>> Hi,
>> On linux test environments which has docker service, `ifconfig` shows that
>> `docker0` appears to be a virtual ethernet bridge which is created by the
>> docker host. And the `docker0` virtual ethern
On Thu, 22 Aug 2024 08:33:05 GMT, SendaoYan wrote:
>> SendaoYan has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - macos may have docker0 interface
>> - macos may have docker0 interface
>
> Thanks f
On Wed, 21 Aug 2024 12:45:22 GMT, SendaoYan wrote:
>> Hi,
>> On linux test environments which has docker service, `ifconfig` shows that
>> `docker0` appears to be a virtual ethernet bridge which is created by the
>> docker host. And the `docker0` virtual ethern
On Wed, 21 Aug 2024 12:45:22 GMT, SendaoYan wrote:
>> Hi,
>> On linux test environments which has docker service, `ifconfig` shows that
>> `docker0` appears to be a virtual ethernet bridge which is created by the
>> docker host. And the `docker0` virtual ethern
On Wed, 21 Aug 2024 12:12:47 GMT, Jaikiran Pai wrote:
> Looks OK to me. Should we be adding that check even within the `if
> (Platform.isOSX()) {` a few lines above? I suspect even macos can have
> `docker0` interface?
I am not sure macos can have `docker0` interface or not, but add that check
iveMaxSize.java` bind `docker0`
> ander network port.
> I think we should just skip "docker0" interfaces when looking for an IPv4
> address for tests.
> Change has been verified, test fix only, the risk is low.
SendaoYan has updated the pull request incrementally with t
On Wed, 21 Aug 2024 03:45:24 GMT, SendaoYan wrote:
> Hi,
> On linux test environments which has docker service, `ifconfig` shows that
> `docker0` appears to be a virtual ethernet bridge which is created by the
> docker host. And the `docker0` virtual ethernet bridge may cause test
On Wed, 21 Aug 2024 03:45:24 GMT, SendaoYan wrote:
> Hi,
> On linux test environments which has docker service, `ifconfig` shows that
> `docker0` appears to be a virtual ethernet bridge which is created by the
> docker host. And the `docker0` virtual ethernet bridge may cause test
Hi,
On linux test environments which has docker service, `ifconfig` shows that
`docker0` appears to be a virtual ethernet bridge which is created by the
docker host. And the `docker0` virtual ethernet bridge may cause test
`java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0
On Fri, 28 Jun 2024 15:36:28 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [f23295ec](https://github.com/openjdk/jdk/commit/f23295ec1dde58d239a2625c9b1645534a2bb625)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
On Fri, 28 Jun 2024 15:36:28 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [f23295ec](https://github.com/openjdk/jdk/commit/f23295ec1dde58d239a2625c9b1645534a2bb625)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
On Fri, 28 Jun 2024 15:36:28 GMT, SendaoYan wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [f23295ec](https://github.com/openjdk/jdk/commit/f23295ec1dde58d239a2625c9b1645534a2bb625)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
On Sat, 29 Jun 2024 06:23:46 GMT, Alan Bateman wrote:
> @dfuch Has you planned to backport this to jdk23?
Before backport to jdk17u-dev and jdk21u-dev, should we backport to jdk23 first.
-
PR Comment: https://git.openjdk.org/jdk/pull/19945#issuecomment-2198209918
Hi all,
This pull request contains a backport of commit
[f23295ec](https://github.com/openjdk/jdk/commit/f23295ec1dde58d239a2625c9b1645534a2bb625)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Daniel Fuchs on 26 Jun 2024 and was
rev
On Fri, 28 Jun 2024 15:05:21 GMT, SendaoYan wrote:
>> Please find here a change that makes the test IPMulticastIF.java more
>> resilient to platform-dependent behavior.
>>
>> The test assumed that you could set any outbound network interface on a
>> bound dat
On Tue, 25 Jun 2024 13:22:38 GMT, Daniel Fuchs wrote:
> Please find here a change that makes the test IPMulticastIF.java more
> resilient to platform-dependent behavior.
>
> The test assumed that you could set any outbound network interface on a bound
> datagram channel. This is in fact system
On Fri, 10 May 2024 01:22:17 GMT, SendaoYan wrote:
>> Hi,
>> The testcase TcpNoDelayNotRequired.java run timeout with -Xcomp jvm
>> options. With -Xcomp jvm options, the jvm consumes a lot of time to compile
>> the java code, but the timeout value is set to 5 second.
On Thu, 9 May 2024 16:44:23 GMT, SendaoYan wrote:
> Hi,
> The testcase TcpNoDelayNotRequired.java run timeout with -Xcomp jvm
> options. With -Xcomp jvm options, the jvm consumes a lot of time to compile
> the java code, but the timeout value is set to 5 second.
>
>
ub.com/sendaoYan/jdk-ysd/actions/runs/9025748732/job/24802572061),
the failure logs says `Artifact name is valid!`, it seems unrelrated to this
PR. So I rerun the failed job.
-
PR Comment: https://git.openjdk.org/jdk/pull/19159#issuecomment-2104147002
On Thu, 9 May 2024 17:17:51 GMT, robert engels wrote:
> Why is this required? I have to assume a lot of testcases with a timeout will
> have this problem.
>
> It seems more that jtreg should subtract out the compilation time from the
> timeout value.
>
> edit: I think it just needs to be adde
On Thu, 9 May 2024 23:53:02 GMT, Jaikiran Pai wrote:
> Hello @sendaoYan, the `vm.flagless` isn't meant for situations like these
> (where we don't spawn any processes within the test). For skipping tests when
> `-Xcomp` is enabled (which we have done for some other test c
eredStopAtLevel=1`
>
> Maybe the 3rd method seems more reasonable.
SendaoYan has updated the pull request incrementally with one additional commit
since the last revision:
change "@requires vm.flagless" to "@requires vm.compMode != \"Xcomp\""
--
Hi,
The testcase TcpNoDelayNotRequired.java run timeout with -Xcomp jvm options.
With -Xcomp jvm options, the jvm consumes a lot of time to compile the java
code, but the timeout value is set to 5 second.
I think it's 3 method to solve this timeout issue.
1. Change timeout value from 5 to 6
72 matches
Mail list logo
