RFR: 8313174: Create fewer predictable port clashes in management tests
Chris Plummer
cjplummer at openjdk.org
Wed Jul 26 17:51:54 UTC 2023
On Wed, 26 Jul 2023 10:50:09 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
> Specifically noticed on linux-aarch64, detection of port clashes by LocateRegistry.createRegistry(port) appears "racy".
>
> Predictable port clashes can be avoided, tests that are likely to run at the same time should not choose the same port.
>
> Why now? The RMI related parts are obviously fairly stable these days, as are the tests themselves.
> Our OS version/host mix for testing may have changed. The problems I looked into were on ol8-aarch64.
>
> It doesn't seem necessary to add complexities to the tests, or change LocateRegistry much at this point, when a simple change to the tests can avoid asking for so many port clashes.
>
>
>
> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java: int port = 5800; // 5801 to 5820
> test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java: int port = 5800; // 5821 to 5840
> test/jdk/javax/management/remote/mandatory/socketFactories/RMISocketFactoriesTest.java: int port = 5800; // 5841 to 5860
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation1Test.java: int port = 5800; // 5861 to 5880
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java: int port = 5800; // 5881 to 5900
> test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation3Test.java: int port = 5800; // 5901 to 5920
Changes requested by cjplummer (Reviewer).
test/jdk/javax/management/remote/mandatory/subjectDelegation/SubjectDelegation2Test.java line 76:
> 74: Registry reg = null;
> 75: int port = 5880;
> 76: while (port++ < 6000) {
Does the loop need to terminate on 5900 instead of 6000?
-------------
PR Review: https://git.openjdk.org/jdk/pull/15039#pullrequestreview-1548296441
PR Review Comment: https://git.openjdk.org/jdk/pull/15039#discussion_r1275303419
More information about the serviceability-dev
mailing list