From jpai at openjdk.org  Mon Apr  1 02:06:51 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 1 Apr 2024 02:06:51 GMT
Subject: jmx-dev RFR: 8328273:
 sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with
 java.rmi.server.ExportException: Port already in use
Message-ID: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>

Can I please get a review of this change which proposes to fix the test failure reported in https://bugs.openjdk.org/browse/JDK-8328273?

As noted in that issue, the `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java` intermittently fails with a port already in use error. The test attempts to find a free port and then uses it during the test. The interesting part is that the test already has a loop of 10 attempts to retry the test if the port wasn't actually free. So for the test to fail, it would then mean that each of the 10 attempts of using a free port failed (which should be extremely rare and should almost never happen). 

I didn't have an answer for that until today and had it on my TODO to look further. Credit goes to Kevin @kevinjwalls for identifying the issue - turns out this is the exact same issue that Kevin fixed in https://github.com/openjdk/jdk/pull/18470 for a different test. After noticing that fix, I spotted the same typo in the exception message check in this test. That explains why it wasn't retrying at most 10 times. The test was thus immediately failing on first attempt whenever the chosen free port was in use.

I have run this test with a test repeat of 50 with this change and the test now passes always. Without this change and a test repeat of 50, the test failed 2 times. I've additionally searched for any other similar typos in other tests and haven't found any (I searched for the string "Exception thrown by the agent :").

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

Commit messages:
 - 8328273: sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with java.rmi.server.ExportException: Port already in use

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

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

From dcubed at openjdk.org  Mon Apr  1 21:00:59 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 1 Apr 2024 21:00:59 GMT
Subject: jmx-dev RFR: 8328273:
 sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with
 java.rmi.server.ExportException: Port already in use
In-Reply-To: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
References: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
Message-ID: <g0erBjRtRY7Z2dfEY6urG_yyFIvgehBPVAy4eHMBfjg=.ab939504-1d53-4a9b-ac6f-3fbf9c2bb5e1@github.com>

On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the test failure reported in https://bugs.openjdk.org/browse/JDK-8328273?
> 
> As noted in that issue, the `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java` intermittently fails with a port already in use error. The test attempts to find a free port and then uses it during the test. The interesting part is that the test already has a loop of 10 attempts to retry the test if the port wasn't actually free. So for the test to fail, it would then mean that each of the 10 attempts of using a free port failed (which should be extremely rare and should almost never happen). 
> 
> I didn't have an answer for that until today and had it on my TODO to look further. Credit goes to Kevin @kevinjwalls for identifying the issue - turns out this is the exact same issue that Kevin fixed in https://github.com/openjdk/jdk/pull/18470 for a different test. After noticing that fix, I spotted the same typo in the exception message check in this test. That explains why it wasn't retrying at most 10 times. The test was thus immediately failing on first attempt whenever the chosen free port was in use.
> 
> I have run this test with a test repeat of 50 with this change and the test now passes always. Without this change and a test repeat of 50, the test failed 2 times. I've additionally searched for any other similar typos in other tests and haven't found any (I searched for the string "Exception thrown by the agent :").

Thumbs up. This is a trivial fix.

@jaikiran - Thanks for fixing this bug!!

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18561#pullrequestreview-1972108656

From jpai at openjdk.org  Tue Apr  2 01:11:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 01:11:58 GMT
Subject: jmx-dev RFR: 8328273:
 sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with
 java.rmi.server.ExportException: Port already in use
In-Reply-To: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
References: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
Message-ID: <M5IE06-x28aoYA4ytia_4L8lJxYy_vpJN56otZkWSEk=.c51dbba7-a928-4f5d-86da-ef1d87798217@github.com>

On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the test failure reported in https://bugs.openjdk.org/browse/JDK-8328273?
> 
> As noted in that issue, the `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java` intermittently fails with a port already in use error. The test attempts to find a free port and then uses it during the test. The interesting part is that the test already has a loop of 10 attempts to retry the test if the port wasn't actually free. So for the test to fail, it would then mean that each of the 10 attempts of using a free port failed (which should be extremely rare and should almost never happen). 
> 
> I didn't have an answer for that until today and had it on my TODO to look further. Credit goes to Kevin @kevinjwalls for identifying the issue - turns out this is the exact same issue that Kevin fixed in https://github.com/openjdk/jdk/pull/18470 for a different test. After noticing that fix, I spotted the same typo in the exception message check in this test. That explains why it wasn't retrying at most 10 times. The test was thus immediately failing on first attempt whenever the chosen free port was in use.
> 
> I have run this test with a test repeat of 50 with this change and the test now passes always. Without this change and a test repeat of 50, the test failed 2 times. I've additionally searched for any other similar typos in other tests and haven't found any (I searched for the string "Exception thrown by the agent :").

Thank you Dan for the review. 

Since this is a test-only trivial fix, I'll go ahead with the integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/18561#issuecomment-2030898184

From jpai at openjdk.org  Tue Apr  2 01:17:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 01:17:04 GMT
Subject: jmx-dev Integrated: 8328273:
 sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with
 java.rmi.server.ExportException: Port already in use
In-Reply-To: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
References: <3Ls58cgxNjNiZ7jjXlDYmTj-9b7hZl5bXaMZcozwWzE=.6fc146e0-d2e1-4ef1-936d-c6a278e0baa8@github.com>
Message-ID: <wNaxTIHnaYdHnJnrHu63ZoYSwwaDk20vQ3230kF7saE=.043707de-d9ce-404d-b1b8-f70526e42c9a@github.com>

On Mon, 1 Apr 2024 02:02:40 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to fix the test failure reported in https://bugs.openjdk.org/browse/JDK-8328273?
> 
> As noted in that issue, the `sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java` intermittently fails with a port already in use error. The test attempts to find a free port and then uses it during the test. The interesting part is that the test already has a loop of 10 attempts to retry the test if the port wasn't actually free. So for the test to fail, it would then mean that each of the 10 attempts of using a free port failed (which should be extremely rare and should almost never happen). 
> 
> I didn't have an answer for that until today and had it on my TODO to look further. Credit goes to Kevin @kevinjwalls for identifying the issue - turns out this is the exact same issue that Kevin fixed in https://github.com/openjdk/jdk/pull/18470 for a different test. After noticing that fix, I spotted the same typo in the exception message check in this test. That explains why it wasn't retrying at most 10 times. The test was thus immediately failing on first attempt whenever the chosen free port was in use.
> 
> I have run this test with a test repeat of 50 with this change and the test now passes always. Without this change and a test repeat of 50, the test failed 2 times. I've additionally searched for any other similar typos in other tests and haven't found any (I searched for the string "Exception thrown by the agent :").

This pull request has now been integrated.

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

8328273: sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java failed with java.rmi.server.ExportException: Port already in use

Reviewed-by: dcubed

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

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

From jpai at openjdk.org  Tue Apr  2 14:49:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 14:49:12 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v4]
In-Reply-To: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
Message-ID: <tqTfOs3OsGnGuNjeZSyKn94BHNFvqLtSx9ulVZceDJw=.09a55777-5bd4-49a7-a588-1595841c010a@github.com>

On Tue, 26 Mar 2024 18:18:39 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/nio/channels/unixdomain/Bind.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/java/nio/channels/unixdomain/NonBlockingAccept.java line 68:

> 66:             // or exception could be thrown otherwise
> 67:         } finally {
> 68:             Files.deleteIfExists(addr.getPath());

Hello Bill, `addr` can be `null` here, so this has a potential of a `NullPointerException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1548038473

From jpai at openjdk.org  Tue Apr  2 14:56:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 14:56:01 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v4]
In-Reply-To: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
Message-ID: <hjGGd5cVG-hz1bHQi2Idj1sEPFmbGAPJtPe9c0B41OU=.057d651f-3341-47c9-94df-1102eaa32fbf@github.com>

On Tue, 26 Mar 2024 18:18:39 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/nio/channels/unixdomain/Bind.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

For the changes in `test/jdk/java/nio/file/Files/CheckPermissions.java` it would be good to have Alan and/or Brian's inputs. The test documentation says that the test relates to SecurityManager checks (and not filesystem permission checks), so the proposed changes in this PR to use a different parent directory for the temporary file(s) should be OK, but I am not familiar with that area to be certain about it.

test/jdk/sun/security/pkcs12/P12SecretKey.java line 69:

> 67: 
> 68:         File ksFile = File.createTempFile("test", ".test");
> 69:         ksFile.deleteOnExit();

Is there a reason why this change is done differently than the rest of the changes in this PR? Can we delete the `File` in a try/finally instead of enrolling a shutdown hook to delete it?

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

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2032269381
PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1548045308

From bhuang at openjdk.org  Tue Apr  2 16:29:21 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 2 Apr 2024 16:29:21 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v5]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

Bill Huang has updated the pull request incrementally with one additional commit since the last revision:

  Implemented review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/0f4130a9..81244609

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=03-04

  Stats: 30 lines in 2 files changed: 12 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

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

From jpai at openjdk.org  Wed Apr  3 01:00:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Apr 2024 01:00:16 GMT
Subject: jmx-dev RFR: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests [v5]
In-Reply-To: <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>
Message-ID: <kgWfaiFMCrvzhuGiWqxLcTEAdH5Tr-n31QeprERgKnA=.df1f42ef-6069-46ff-9985-f0731bb1c5b3@github.com>

On Tue, 2 Apr 2024 16:29:21 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Thank you for the update, Bill. The latest changes look OK to me.
I also heard from Bill that Alan has approved the changes too.

Before integrating, please run tier1, tier2 and tier3 (I haven't checked which tiers these changed tests belong to) to make sure nothing breaks unexpectedly.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18352#pullrequestreview-1975307573

From bhuang at openjdk.org  Wed Apr  3 17:07:12 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 3 Apr 2024 17:07:12 GMT
Subject: jmx-dev Integrated: JDK-8327474 Review use of java.io.tmpdir in jdk
 tests
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <4fPL8biQ1uu8AMKMNmt3x0yLRKa01iDp6OL5MXQgasM=.bc20a303-65dc-48b2-80eb-b9ef6cd15b00@github.com>

On Mon, 18 Mar 2024 16:47:24 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

This pull request has now been integrated.

Changeset: 375bfac8
Author:    Bill Huang <bhuang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/375bfac8e7ff3f871e2d986876f91a5fba200c83
Stats:     193 lines in 11 files changed: 66 ins; 13 del; 114 mod

8327474: Review use of java.io.tmpdir in jdk tests

Reviewed-by: michaelm, jpai

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

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

From kevinw at openjdk.org  Thu Apr  4 13:09:22 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Apr 2024 13:09:22 GMT
Subject: jmx-dev RFR: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature [v16]
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <963ScTZ1CLP5cWVO79g03y7FLuDbv5xn5-vGcWjTqkA=.2a5006b3-b308-4032-9179-6ebead9833d1@github.com>

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge remote-tracking branch 'upstream/master' into 8326666_SubjectDelegation_remove
 - Merge
 - Missing code doc nit.
 - Missing code doc nit.
 - RMIConnectionImpl_Stub also should explicity inherit the unchecked UOE.
 - Clarify JMXConnector equivalence comment.
 - RMIConnectionImpl needs to explicity inherit the unchecked UOE.
 - typo
 - Javadoc update
 - Remove unnecessary constructor in private class
 - ... and 15 more: https://git.openjdk.org/jdk/compare/b9da1401...7fec01c7

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

Changes: https://git.openjdk.org/jdk/pull/18025/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18025&range=15
  Stats: 2026 lines in 35 files changed: 214 ins; 1632 del; 180 mod
  Patch: https://git.openjdk.org/jdk/pull/18025.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18025/head:pull/18025

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

From kevinw at openjdk.org  Thu Apr  4 16:57:22 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 4 Apr 2024 16:57:22 GMT
Subject: jmx-dev Integrated: 8326666: Remove the Java Management Extension
 (JMX) Subject Delegation feature
In-Reply-To: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
References: <7hBwkCdT6j4MH-I7djOtP87t6kR44ahNHDdGBZkjO-I=.31a76702-9a66-4937-bb3e-cfb2845e7a16@github.com>
Message-ID: <y59ZhqXuUh16j84Kj86wo2xYXv_Pb3ldt6YkgaTk064=.c824b6f0-f0bd-4516-9848-fd198ae77738@github.com>

On Tue, 27 Feb 2024 10:44:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The deprecated Subject Delegation feature in JMX will be removed.
> 
> This was marked in JDK 21 as deprecated for removal (JDK-8298966).

This pull request has now been integrated.

Changeset: 6382a129
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6382a1290fbd7cc8fd097a2972bfcfc06fa4de79
Stats:     2026 lines in 35 files changed: 214 ins; 1632 del; 180 mod

8326666: Remove the Java Management Extension (JMX) Subject Delegation feature

Reviewed-by: mchung, dfuchs

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

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

From kevinw at openjdk.org  Tue Apr  9 11:24:29 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 9 Apr 2024 11:24:29 GMT
Subject: jmx-dev RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock
Message-ID: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>

This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.

Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)

When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.

We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.

Show the stackframes on all failures.

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

Commit messages:
 - 8188784: javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST FAILED: deadlock

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

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

From cjplummer at openjdk.org  Wed Apr 10 04:31:09 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 10 Apr 2024 04:31:09 GMT
Subject: jmx-dev RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock
In-Reply-To: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
Message-ID: <SfNnI6kzhSrCKnUCXYX4kqO_843m-2StAFcI427C1V8=.4dac2e0e-e3e1-47ed-8eaa-fa7929cde6df@github.com>

On Tue, 9 Apr 2024 11:08:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
> A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.
> 
> Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)
> 
> When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.
> 
> We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.
> 
> Show the stackframes on all failures.

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18687#pullrequestreview-1990774500

From lmesnik at openjdk.org  Tue Apr 16 00:33:59 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 Apr 2024 00:33:59 GMT
Subject: jmx-dev RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock
In-Reply-To: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
Message-ID: <hOfioQFVmMR-FT9T1oDOYjeF3IAKnpUkzkc7v8FjCk4=.f5fa1d34-defb-4357-b286-847abcdc3afe@github.com>

On Tue, 9 Apr 2024 11:08:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
> A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.
> 
> Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)
> 
> When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.
> 
> We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.
> 
> Show the stackframes on all failures.

Marked as reviewed by lmesnik (Reviewer).

test/jdk/javax/management/notification/BroadcasterSupportDeadlockTest.java line 122:

> 120:         java.util.Map<Thread,StackTraceElement[]> traces = Thread.getAllStackTraces();
> 121:         showStackTrace("Thread 1", traces.get(t1));
> 122:         showStackTrace("Thread 2", traces.get(t2));

Could you please replace System.exit() with throwing Exception. Other looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/18687#pullrequestreview-2002384686
PR Review Comment: https://git.openjdk.org/jdk/pull/18687#discussion_r1566573453

From kevinw at openjdk.org  Tue Apr 16 09:26:58 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Apr 2024 09:26:58 GMT
Subject: jmx-dev RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock [v2]
In-Reply-To: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
Message-ID: <zNYQk_LWVIte9YYR3Qjpj6OYqmUuYhCjkhoBZR2b75k=.6d622898-3eb1-414a-99a9-7fd46c8565e6@github.com>

> This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
> A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.
> 
> Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)
> 
> When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.
> 
> We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.
> 
> Show the stackframes on all failures.

Kevin Walls 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 three additional commits since the last revision:

 - Remove System.exit calls
 - Merge remote-tracking branch 'upstream/master' into 8188784_BroadcasterSupportDeadlockTest
 - 8188784: javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST FAILED: deadlock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18687/files
  - new: https://git.openjdk.org/jdk/pull/18687/files/5237f1d8..a77b3c85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18687&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18687&range=00-01

  Stats: 16713 lines in 561 files changed: 8813 ins; 4016 del; 3884 mod
  Patch: https://git.openjdk.org/jdk/pull/18687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18687/head:pull/18687

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

From kevinw at openjdk.org  Tue Apr 16 10:11:00 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Apr 2024 10:11:00 GMT
Subject: jmx-dev RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock [v2]
In-Reply-To: <hOfioQFVmMR-FT9T1oDOYjeF3IAKnpUkzkc7v8FjCk4=.f5fa1d34-defb-4357-b286-847abcdc3afe@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
 <hOfioQFVmMR-FT9T1oDOYjeF3IAKnpUkzkc7v8FjCk4=.f5fa1d34-defb-4357-b286-847abcdc3afe@github.com>
Message-ID: <YUvduyikE_xss-IuI9nbJN0MM6NWAue8K2yTTpBj4-E=.11b13182-ded4-4b77-ad85-1d14eb12a4ec@github.com>

On Tue, 16 Apr 2024 00:31:10 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Kevin Walls 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 three additional commits since the last revision:
>> 
>>  - Remove System.exit calls
>>  - Merge remote-tracking branch 'upstream/master' into 8188784_BroadcasterSupportDeadlockTest
>>  - 8188784: javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST FAILED: deadlock
>
> test/jdk/javax/management/notification/BroadcasterSupportDeadlockTest.java line 122:
> 
>> 120:         java.util.Map<Thread,StackTraceElement[]> traces = Thread.getAllStackTraces();
>> 121:         showStackTrace("Thread 1", traces.get(t1));
>> 122:         showStackTrace("Thread 2", traces.get(t2));
> 
> Could you please replace System.exit() with throwing Exception. Other looks good.

OK sure.
FYI I count 137 System.exit calls in test/jdk/javax/management
That's after I take out the existing 3 that are in this test. 8-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18687#discussion_r1567098465

From kevinw at openjdk.org  Tue Apr 16 10:24:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Apr 2024 10:24:09 GMT
Subject: jmx-dev RFR: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock [v2]
In-Reply-To: <zNYQk_LWVIte9YYR3Qjpj6OYqmUuYhCjkhoBZR2b75k=.6d622898-3eb1-414a-99a9-7fd46c8565e6@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
 <zNYQk_LWVIte9YYR3Qjpj6OYqmUuYhCjkhoBZR2b75k=.6d622898-3eb1-414a-99a9-7fd46c8565e6@github.com>
Message-ID: <VR9cYyLlSnYr_daO-gDaRRsbulEPkcRSrHRSkCYqmXg=.fc4d3054-7b4e-4554-9886-e8bf8b52a38f@github.com>

On Tue, 16 Apr 2024 09:26:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
>> A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.
>> 
>> Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)
>> 
>> When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.
>> 
>> We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.
>> 
>> Show the stackframes on all failures.
>
> Kevin Walls 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 three additional commits since the last revision:
> 
>  - Remove System.exit calls
>  - Merge remote-tracking branch 'upstream/master' into 8188784_BroadcasterSupportDeadlockTest
>  - 8188784: javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST FAILED: deadlock

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/18687#issuecomment-2058745011

From kevinw at openjdk.org  Tue Apr 16 10:24:09 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 16 Apr 2024 10:24:09 GMT
Subject: jmx-dev Integrated: 8188784:
 javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST
 FAILED: deadlock
In-Reply-To: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
References: <SjE2qD8hJjpNsEKrYBEzJm--eJ3p21uZS7M6ydlB8ow=.1bd99464-5794-4cb6-80b6-3245e8b71c39@github.com>
Message-ID: <92KFus1vIHrR2uVBvRzhSd51pXFqZ-tEopxHlaRd6Vg=.efce87cc-cce8-4722-8fbb-c1f397e3bc4b@github.com>

On Tue, 9 Apr 2024 11:08:31 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test incorrectly fails, although rarely, thinking its "thread 2" has deadlocked.
> A change of sleep will likely fix this, but there are other issues, so cleaning up the test a little.
> 
> Remove the probe for the ManagementFactory class, to check we are on jdk5 or later. 8-)
> 
> When sleeping, sleep 100, not 1ms, we don't need to spin fast and actually race with the other thread.
> 
> We have a 1000 iteration loop, but don't seem to use it.  We only check once then either return (pass), fail, or break (which is also fail).  Use the loop to check for the status change, which is likely what was intended.
> 
> Show the stackframes on all failures.

This pull request has now been integrated.

Changeset: 58911ccc
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/58911ccc2c48b4b5dd2ebc9d2a44dcf3737eca50
Stats:     42 lines in 1 file changed: 9 ins; 21 del; 12 mod

8188784: javax/management/notification/BroadcasterSupportDeadlockTest.java - TEST FAILED: deadlock

Reviewed-by: cjplummer, lmesnik

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

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