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. Ok. Should I continue with the separation of this test in that PR or in a new one (as @seanjmullan said)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31812#discussion_r3568943461
