On Thu, 9 Jul 2026 12:15:15 GMT, Sean Mullan <[email protected]> wrote:
>> I actually looked into this approach. One complication is that building the >> test matrix requires a fresh JVM where SSLContext has not been initialized >> yet. Once SSLContext has been initialized, changing >> jdk.tls.disabledAlgorithms via Security.setProperty() does not appear to >> have the desired effect anymore. >> >> So, i am fine with changing the timeout for the `visibility` test to 480 and >> keeping the 'default' for the `handshake` test > > I think changing the `visibility` test to 480 is a good short-term fix. > However, I don't think spawning 270 VMs is a good use of test resources for a > single test. We need to keep in mind that these tests are run continuously by > many developers. > > I'd suggest filing another issue and explore a couple of different ways to > reduce the number of VMs: > > 1) you could reduce the number of VMs significantly by setting the > `jdk.tls.disabledAlgorithms` property set to all of the cipher suites that > are to be tested, and then test TLS with each cipher suite to ensure it is > properly disabled. Though this would not give you the isolation that you have > now, I think it would still catch the issue that caused this bug. > > 2) You could randomly select a subset of cipher suites to be tested, instead > of all of them. And you could add a 3rd run option that would be a manual > test which would run all of them. Thanks for your suggestions. I've also been thinking about ways to reduce the number of spawned VMs. To be honest, I prefer the simple and isolated test design used here. The goal is not only to test the specific code path that caused this bug, but also to provide broader coverage of the feature's behavior. My suggestion would be to get the short-term fix in first, and then I can file a follow-up issue to explore a redesign of the test. I will take care of that asap. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31812#discussion_r3551947579
