From kevinw at openjdk.org  Wed Nov  1 18:16:40 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 1 Nov 2023 18:16:40 GMT
Subject: jmx-dev RFR: 8319238: JMX ThreadPoolAccTest.java is too verbose and
 should fail before timeout
Message-ID: <vekfi3O-pTfwFkd54rv2eRjtQapkGc9OGjOI5AeDgiA=.73dfd3a3-8a5b-408a-a89f-dd2bb11d81e0@github.com>

Discovered while testing changes that made this test fail.  The test failure is hard to diagnose as it logs and retries at full speed, possibly forever, until timeout.  This can hit a log file limit.  We can save thousands of lines of text being printed when the test runs normally and successfully, by waiting half a second before doing the Principal-checking which is the purpose of the test.

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

Commit messages:
 - 8319238: JMX ThreadPoolAccTest.java is too verbose and should fail before timeout

Changes: https://git.openjdk.org/jdk/pull/16456/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16456&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319238
  Stats: 26 lines in 1 file changed: 23 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16456/head:pull/16456

PR: https://git.openjdk.org/jdk/pull/16456

From sspitsyn at openjdk.org  Thu Nov  2 15:50:05 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 Nov 2023 15:50:05 GMT
Subject: jmx-dev RFR: 8319238: JMX ThreadPoolAccTest.java is too verbose
 and should fail before timeout
In-Reply-To: <vekfi3O-pTfwFkd54rv2eRjtQapkGc9OGjOI5AeDgiA=.73dfd3a3-8a5b-408a-a89f-dd2bb11d81e0@github.com>
References: <vekfi3O-pTfwFkd54rv2eRjtQapkGc9OGjOI5AeDgiA=.73dfd3a3-8a5b-408a-a89f-dd2bb11d81e0@github.com>
Message-ID: <32Rz8M0A865KTiasBJpx8UcEFTJGTfQ4heV0OLw6RkM=.eb68f176-f04e-44af-8170-77fb2e631c8e@github.com>

On Wed, 1 Nov 2023 17:10:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Discovered while testing changes that made this test fail.  The test failure is hard to diagnose as it logs and retries at full speed, possibly forever, until timeout.  This can hit a log file limit.  We can save thousands of lines of text being printed when the test runs normally and successfully, by waiting half a second before doing the Principal-checking which is the purpose of the test.

Looks reasonable.
Thanks,
Serguei

test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 167:

> 165:             String expected = principals[i / 3];
> 166: 
> 167:             echo("testPrincipals: monitored: " + monitored[i] + " principal: " + principal + " expected: " + expected);

With this in place, should printing of principal at line 176 be removed?

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16456#pullrequestreview-1710643924
PR Review Comment: https://git.openjdk.org/jdk/pull/16456#discussion_r1380362829

From kevinw at openjdk.org  Thu Nov  2 18:19:05 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 2 Nov 2023 18:19:05 GMT
Subject: jmx-dev RFR: 8319238: JMX ThreadPoolAccTest.java is too verbose
 and should fail before timeout
In-Reply-To: <32Rz8M0A865KTiasBJpx8UcEFTJGTfQ4heV0OLw6RkM=.eb68f176-f04e-44af-8170-77fb2e631c8e@github.com>
References: <vekfi3O-pTfwFkd54rv2eRjtQapkGc9OGjOI5AeDgiA=.73dfd3a3-8a5b-408a-a89f-dd2bb11d81e0@github.com>
 <32Rz8M0A865KTiasBJpx8UcEFTJGTfQ4heV0OLw6RkM=.eb68f176-f04e-44af-8170-77fb2e631c8e@github.com>
Message-ID: <Fuq-hXCN_1YdbL3EIoqH7r7Ry8Xt3ui5uMycFLV66BE=.4bf44bbe-6aaa-4894-8550-8a7cdd99a067@github.com>

On Thu, 2 Nov 2023 15:47:00 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Discovered while testing changes that made this test fail.  The test failure is hard to diagnose as it logs and retries at full speed, possibly forever, until timeout.  This can hit a log file limit.  We can save thousands of lines of text being printed when the test runs normally and successfully, by waiting half a second before doing the Principal-checking which is the purpose of the test.
>
> test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 167:
> 
>> 165:             String expected = principals[i / 3];
>> 166: 
>> 167:             echo("testPrincipals: monitored: " + monitored[i] + " principal: " + principal + " expected: " + expected);
> 
> With this in place, should printing of principal at line 176 be removed?

Right, it is duplicated.  That new line is useful, I really wanted to see something before we check for null.
Then we have the existing printing before we check further, which I did not disturb.  I'm sure it's not a big deal either way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16456#discussion_r1380610946

From sspitsyn at openjdk.org  Fri Nov  3 06:39:01 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 3 Nov 2023 06:39:01 GMT
Subject: jmx-dev RFR: 8319238: JMX ThreadPoolAccTest.java is too verbose
 and should fail before timeout
In-Reply-To: <Fuq-hXCN_1YdbL3EIoqH7r7Ry8Xt3ui5uMycFLV66BE=.4bf44bbe-6aaa-4894-8550-8a7cdd99a067@github.com>
References: <vekfi3O-pTfwFkd54rv2eRjtQapkGc9OGjOI5AeDgiA=.73dfd3a3-8a5b-408a-a89f-dd2bb11d81e0@github.com>
 <32Rz8M0A865KTiasBJpx8UcEFTJGTfQ4heV0OLw6RkM=.eb68f176-f04e-44af-8170-77fb2e631c8e@github.com>
 <Fuq-hXCN_1YdbL3EIoqH7r7Ry8Xt3ui5uMycFLV66BE=.4bf44bbe-6aaa-4894-8550-8a7cdd99a067@github.com>
Message-ID: <sZoxJQvvXhDDLXKW7utjfUmMLlarfNaPoVkcndcGSX8=.e05939af-e109-4760-a68a-2a86b272cda1@github.com>

On Thu, 2 Nov 2023 18:16:49 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> test/jdk/javax/management/monitor/ThreadPoolAccTest.java line 167:
>> 
>>> 165:             String expected = principals[i / 3];
>>> 166: 
>>> 167:             echo("testPrincipals: monitored: " + monitored[i] + " principal: " + principal + " expected: " + expected);
>> 
>> With this in place, should printing of principal at line 176 be removed?
>
> Right, it is duplicated.  That new line is useful, I really wanted to see something before we check for null.
> Then we have the existing printing before we check further, which I did not disturb.  I'm sure it's not a big deal either way.

Up to you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16456#discussion_r1381203169

From jpai at openjdk.org  Mon Nov  6 07:02:19 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 6 Nov 2023 07:02:19 GMT
Subject: jmx-dev RFR: 8319465: Typos in javadoc of
 com.sun.management.OperatingSystemMXBean methods
Message-ID: <Gt64kNGsC2lENoGdYfpxVmLJRuek99S8GUaVJZ9XWLI=.b46e3668-4da1-469e-9509-63251107701e@github.com>

Can I please get a review of this PR which fixes the typos in the method javadocs of com.sun.management.OperatingSystemMXBean? 

As noted in https://bugs.openjdk.org/browse/JDK-8319465, this PR replaces the word "betweens" by "between"

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

Commit messages:
 - 8319465: Typos in javadoc of com.sun.management.OperatingSystemMXBean methods

Changes: https://git.openjdk.org/jdk/pull/16516/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16516&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319465
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16516.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16516/head:pull/16516

PR: https://git.openjdk.org/jdk/pull/16516

From dholmes at openjdk.org  Mon Nov  6 07:55:07 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Nov 2023 07:55:07 GMT
Subject: jmx-dev RFR: 8319465: Typos in javadoc of
 com.sun.management.OperatingSystemMXBean methods
In-Reply-To: <Gt64kNGsC2lENoGdYfpxVmLJRuek99S8GUaVJZ9XWLI=.b46e3668-4da1-469e-9509-63251107701e@github.com>
References: <Gt64kNGsC2lENoGdYfpxVmLJRuek99S8GUaVJZ9XWLI=.b46e3668-4da1-469e-9509-63251107701e@github.com>
Message-ID: <2Tal46ut9irLVgKlnknF58R2lJqhaSBRUWDT98rAuhM=.d586df2a-95a9-48c8-835f-60c52defaeb2@github.com>

On Mon, 6 Nov 2023 06:55:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this PR which fixes the typos in the method javadocs of com.sun.management.OperatingSystemMXBean? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8319465, this PR replaces the word "betweens" by "between"

Looks good and trivial. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16516#pullrequestreview-1714446331

From kevinw at openjdk.org  Mon Nov  6 11:22:12 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 6 Nov 2023 11:22:12 GMT
Subject: jmx-dev RFR: 8319465: Typos in javadoc of
 com.sun.management.OperatingSystemMXBean methods
In-Reply-To: <Gt64kNGsC2lENoGdYfpxVmLJRuek99S8GUaVJZ9XWLI=.b46e3668-4da1-469e-9509-63251107701e@github.com>
References: <Gt64kNGsC2lENoGdYfpxVmLJRuek99S8GUaVJZ9XWLI=.b46e3668-4da1-469e-9509-63251107701e@github.com>
Message-ID: <36GlvvOjhpn8DBopNnUItDelKQAV7LYv-izg58OwQIY=.f0f5db1c-2c76-416b-91b5-e2e4df6984aa@github.com>

On Mon, 6 Nov 2023 06:55:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this PR which fixes the typos in the method javadocs of com.sun.management.OperatingSystemMXBean? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8319465, this PR replaces the word "betweens" by "between"

Marked as reviewed by kevinw (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/16516#pullrequestreview-1714886414

From dfuchs at openjdk.org  Mon Nov  6 12:29:08 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 6 Nov 2023 12:29:08 GMT
Subject: jmx-dev RFR: 8319465: Typos in javadoc of
 com.sun.management.OperatingSystemMXBean methods
In-Reply-To: <Gt64kNGsC2lENoGdYfpxVmLJRuek99S8GUaVJZ9XWLI=.b46e3668-4da1-469e-9509-63251107701e@github.com>
References: <Gt64kNGsC2lENoGdYfpxVmLJRuek99S8GUaVJZ9XWLI=.b46e3668-4da1-469e-9509-63251107701e@github.com>
Message-ID: <6JbKmC6mi4Zv57ozdszwv7VC3Itm-CvpOlMbg7sYAEE=.9bd5c172-2698-4803-a018-fe4227c5f533@github.com>

On Mon, 6 Nov 2023 06:55:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this PR which fixes the typos in the method javadocs of com.sun.management.OperatingSystemMXBean? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8319465, this PR replaces the word "betweens" by "between"

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16516#pullrequestreview-1715042344

From jpai at openjdk.org  Mon Nov  6 12:58:11 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 6 Nov 2023 12:58:11 GMT
Subject: jmx-dev RFR: 8319465: Typos in javadoc of
 com.sun.management.OperatingSystemMXBean methods
In-Reply-To: <Gt64kNGsC2lENoGdYfpxVmLJRuek99S8GUaVJZ9XWLI=.b46e3668-4da1-469e-9509-63251107701e@github.com>
References: <Gt64kNGsC2lENoGdYfpxVmLJRuek99S8GUaVJZ9XWLI=.b46e3668-4da1-469e-9509-63251107701e@github.com>
Message-ID: <99949XXBV5pfmhYOakTZ4qfiHFxELtjE6KlkK2eFaq4=.c4a82dd9-a2c5-4b79-9016-06ff5174d258@github.com>

On Mon, 6 Nov 2023 06:55:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this PR which fixes the typos in the method javadocs of com.sun.management.OperatingSystemMXBean? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8319465, this PR replaces the word "betweens" by "between"

Thank you everyone for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/16516#issuecomment-1794756060

From jpai at openjdk.org  Mon Nov  6 13:01:19 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 6 Nov 2023 13:01:19 GMT
Subject: jmx-dev Integrated: 8319465: Typos in javadoc of
 com.sun.management.OperatingSystemMXBean methods
In-Reply-To: <Gt64kNGsC2lENoGdYfpxVmLJRuek99S8GUaVJZ9XWLI=.b46e3668-4da1-469e-9509-63251107701e@github.com>
References: <Gt64kNGsC2lENoGdYfpxVmLJRuek99S8GUaVJZ9XWLI=.b46e3668-4da1-469e-9509-63251107701e@github.com>
Message-ID: <oOm3-Z1zeI3BEmySS-YqvoO5ubzECBv5r7EyTV2R-Wc=.86692195-2222-4d74-b066-66bdd0c7b602@github.com>

On Mon, 6 Nov 2023 06:55:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this PR which fixes the typos in the method javadocs of com.sun.management.OperatingSystemMXBean? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8319465, this PR replaces the word "betweens" by "between"

This pull request has now been integrated.

Changeset: 2d4bbf47
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d4bbf478745e62584420bfdef5a4948edac54ad
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8319465: Typos in javadoc of com.sun.management.OperatingSystemMXBean methods

Reviewed-by: dholmes, kevinw, dfuchs

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

PR: https://git.openjdk.org/jdk/pull/16516

From kevinw at openjdk.org  Tue Nov  7 10:18:40 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 7 Nov 2023 10:18:40 GMT
Subject: jmx-dev Integrated: 8319238: JMX ThreadPoolAccTest.java is too
 verbose and should fail before timeout
In-Reply-To: <vekfi3O-pTfwFkd54rv2eRjtQapkGc9OGjOI5AeDgiA=.73dfd3a3-8a5b-408a-a89f-dd2bb11d81e0@github.com>
References: <vekfi3O-pTfwFkd54rv2eRjtQapkGc9OGjOI5AeDgiA=.73dfd3a3-8a5b-408a-a89f-dd2bb11d81e0@github.com>
Message-ID: <RRlyAhadOEum7P9P-WKd4TX57f5ZyLf1oXRAYgcJR1s=.7a538f92-72df-4c2a-bc5c-10c9ba74ba38@github.com>

On Wed, 1 Nov 2023 17:10:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Discovered while testing changes that made this test fail.  The test failure is hard to diagnose as it logs and retries at full speed, possibly forever, until timeout.  This can hit a log file limit.  We can save thousands of lines of text being printed when the test runs normally and successfully, by waiting half a second before doing the Principal-checking which is the purpose of the test.

This pull request has now been integrated.

Changeset: a7c01902
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a7c0190230825e998bb534721ed3c22904efdbb4
Stats:     26 lines in 1 file changed: 23 ins; 0 del; 3 mod

8319238: JMX ThreadPoolAccTest.java is too verbose and should fail before timeout

Reviewed-by: sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/16456

From kevinw at openjdk.org  Tue Nov 21 13:09:14 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 21 Nov 2023 13:09:14 GMT
Subject: jmx-dev RFR: 8313355:
 javax/management/remote/mandatory/notif/ListenerScaleTest.java failed with
 "Exception: Failed: ratio=792.2791601423487"
Message-ID: <tyskBSUJVUXQ-aZxB2vRlarC0gWDZjS6v5Qq468FrzM=.c1eae685-9207-4552-af7a-d3af24a2ed43@github.com>

This test fails occasionally, and can be tuned to avoid most of the failures ever seen.

It exists to check that notification work does not scale linearly with number of MBeans, so it calculates a ratio of the time taken with one, and with 20,000 MBeans.

We should increase point at which that calculated ratio is considered a failure.  I chose 2500 here as it solves most of the failures that I think have ever been reported with the test, without being too forgiving that we ignore a serious slowdown in future.

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

Commit messages:
 - 8313355: javax/management/remote/mandatory/notif/ListenerScaleTest.java failed with "Exception: Failed: ratio=792.2791601423487"

Changes: https://git.openjdk.org/jdk/pull/16761/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16761&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313355
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16761.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16761/head:pull/16761

PR: https://git.openjdk.org/jdk/pull/16761

From sspitsyn at openjdk.org  Mon Nov 27 19:28:04 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 27 Nov 2023 19:28:04 GMT
Subject: jmx-dev RFR: 8313355:
 javax/management/remote/mandatory/notif/ListenerScaleTest.java failed with
 "Exception: Failed: ratio=792.2791601423487"
In-Reply-To: <tyskBSUJVUXQ-aZxB2vRlarC0gWDZjS6v5Qq468FrzM=.c1eae685-9207-4552-af7a-d3af24a2ed43@github.com>
References: <tyskBSUJVUXQ-aZxB2vRlarC0gWDZjS6v5Qq468FrzM=.c1eae685-9207-4552-af7a-d3af24a2ed43@github.com>
Message-ID: <_WtXstBBmZJOwoes43uiOaJxDBI6w2GXZGmKEE5w7r0=.e659c9ec-177d-49a9-87d1-f979b8fce866@github.com>

On Tue, 21 Nov 2023 13:01:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails occasionally, and can be tuned to avoid most of the failures ever seen.
> 
> It exists to check that notification work does not scale linearly with number of MBeans, so it calculates a ratio of the time taken with one, and with 20,000 MBeans.
> 
> We should increase point at which that calculated ratio is considered a failure.  I chose 2500 here as it solves most of the failures that I think have ever been reported with the test, without being too forgiving that we ignore a serious slowdown in future.

Looks okay and trivial to me.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16761#pullrequestreview-1751200573

From kevinw at openjdk.org  Tue Nov 28 09:51:20 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 28 Nov 2023 09:51:20 GMT
Subject: jmx-dev RFR: 8313355:
 javax/management/remote/mandatory/notif/ListenerScaleTest.java failed with
 "Exception: Failed: ratio=792.2791601423487"
In-Reply-To: <tyskBSUJVUXQ-aZxB2vRlarC0gWDZjS6v5Qq468FrzM=.c1eae685-9207-4552-af7a-d3af24a2ed43@github.com>
References: <tyskBSUJVUXQ-aZxB2vRlarC0gWDZjS6v5Qq468FrzM=.c1eae685-9207-4552-af7a-d3af24a2ed43@github.com>
Message-ID: <LgHC65p13KvbrAwUfTo8jHuuR7EmiHqNZ2vk8ihvGMM=.1d69993b-582d-4912-8198-82d0015841d9@github.com>

On Tue, 21 Nov 2023 13:01:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails occasionally, and can be tuned to avoid most of the failures ever seen.
> 
> It exists to check that notification work does not scale linearly with number of MBeans, so it calculates a ratio of the time taken with one, and with 20,000 MBeans.
> 
> We should increase point at which that calculated ratio is considered a failure.  I chose 2500 here as it solves most of the failures that I think have ever been reported with the test, without being too forgiving that we ignore a serious slowdown in future.

Thanks Serguei.

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

PR Comment: https://git.openjdk.org/jdk/pull/16761#issuecomment-1829455159

From kevinw at openjdk.org  Tue Nov 28 09:51:20 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 28 Nov 2023 09:51:20 GMT
Subject: jmx-dev Integrated: 8313355:
 javax/management/remote/mandatory/notif/ListenerScaleTest.java failed with
 "Exception: Failed: ratio=792.2791601423487"
In-Reply-To: <tyskBSUJVUXQ-aZxB2vRlarC0gWDZjS6v5Qq468FrzM=.c1eae685-9207-4552-af7a-d3af24a2ed43@github.com>
References: <tyskBSUJVUXQ-aZxB2vRlarC0gWDZjS6v5Qq468FrzM=.c1eae685-9207-4552-af7a-d3af24a2ed43@github.com>
Message-ID: <jaBwQarMB_GNyK3atrgemnOb6vzxDShWsts7mkntYJo=.00345969-b3f2-44b8-840c-3c856c12bd03@github.com>

On Tue, 21 Nov 2023 13:01:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test fails occasionally, and can be tuned to avoid most of the failures ever seen.
> 
> It exists to check that notification work does not scale linearly with number of MBeans, so it calculates a ratio of the time taken with one, and with 20,000 MBeans.
> 
> We should increase point at which that calculated ratio is considered a failure.  I chose 2500 here as it solves most of the failures that I think have ever been reported with the test, without being too forgiving that we ignore a serious slowdown in future.

This pull request has now been integrated.

Changeset: debf0ecf
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/debf0ecfb0076f5513595c74038215520d630764
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8313355: javax/management/remote/mandatory/notif/ListenerScaleTest.java failed with "Exception: Failed: ratio=792.2791601423487"

Reviewed-by: sspitsyn

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

PR: https://git.openjdk.org/jdk/pull/16761

From kevinw at openjdk.org  Tue Nov 28 17:26:26 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 28 Nov 2023 17:26:26 GMT
Subject: jmx-dev RFR: 8316649: JMX connection timeout cannot be changed and
 uses the default of 0 (infinite)
Message-ID: <Gi22n5dk8qOvO9oa-nSvkBDiYfShFlyjGH-0hvs5E4c=.cb6d8f8b-9971-4363-a776-c513550ded56@github.com>

JMX RMI Connections should use a timeout on the Socket connect call by default.

JMX Connections use RMI and some connection failures never terminate. The hang described in 8316649 is hard to reproduce manually: the description says it can be caused by a firewall that never returns a response.

Changing the base RMI implementation may not be desirable at this time.

JMX can use a new ClientSocketFactory for RMI which implements the connect timeout, which can recognise a new JMX-specific property `com.sun.management.jmxremote.rmi.tcpConnectTimeout`
(named like the existing com.sun.management.jmxremote... properties)

Defaulting to a 1 minute timeout on connect has no effect on existing tests, and should go unnoticed unless there really is a significant connection delay. Specifying zero for the new System Property will use the old technique of a connect with no timeout.

This can be tested, but it is not realistically usable: although specifying a 1 millisecond timeout will often fail (as expected/desired for the test), it will very often pass as the connection happens immediately.

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

Commit messages:
 - whitespace
 - remove commented out code
 - complete class rename
 - 8316649: JMX connection timeout cannot be changed and uses the default of 0 (infinite)

Changes: https://git.openjdk.org/jdk/pull/16856/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16856&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316649
  Stats: 72 lines in 2 files changed: 68 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16856.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16856/head:pull/16856

PR: https://git.openjdk.org/jdk/pull/16856

From dfuchs at openjdk.org  Tue Nov 28 17:59:08 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 28 Nov 2023 17:59:08 GMT
Subject: jmx-dev RFR: 8316649: JMX connection timeout cannot be changed
 and uses the default of 0 (infinite)
In-Reply-To: <Gi22n5dk8qOvO9oa-nSvkBDiYfShFlyjGH-0hvs5E4c=.cb6d8f8b-9971-4363-a776-c513550ded56@github.com>
References: <Gi22n5dk8qOvO9oa-nSvkBDiYfShFlyjGH-0hvs5E4c=.cb6d8f8b-9971-4363-a776-c513550ded56@github.com>
Message-ID: <dfcJHaysetsmvtgi9ZLzBwR4nhJxNs8s5AExGrDt1HI=.68b81cfc-4fc1-4dde-a971-4267bd890b6f@github.com>

On Tue, 28 Nov 2023 16:21:29 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> JMX RMI Connections should use a timeout on the Socket connect call by default.
> 
> JMX Connections use RMI and some connection failures never terminate. The hang described in 8316649 is hard to reproduce manually: the description says it can be caused by a firewall that never returns a response.
> 
> Changing the base RMI implementation may not be desirable at this time.
> 
> JMX can use a new ClientSocketFactory for RMI which implements the connect timeout, which can recognise a new JMX-specific property `com.sun.management.jmxremote.rmi.tcpConnectTimeout`
> (named like the existing com.sun.management.jmxremote... properties)
> 
> Defaulting to a 1 minute timeout on connect has no effect on existing tests, and should go unnoticed unless there really is a significant connection delay. Specifying zero for the new System Property will use the old technique of a connect with no timeout.
> 
> This can be tested, but it is not realistically usable: although specifying a 1 millisecond timeout will often fail (as expected/desired for the test), it will very often pass as the connection happens immediately.

I don't think that's a good idea. AFAIK the RMIClientSocketFactory is serialized and sent by the server to the client. This means, unless I'm mistaken, that you will not be able to use JDK 21 JConsole to connect to a JDK 22 VM. Try it :-)
If you chose to go this route then use of the factory should be an opt-in.

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

PR Comment: https://git.openjdk.org/jdk/pull/16856#issuecomment-1830389934