Hi Daniil,
84 // If new MBean (e.g. Graal MBean) is registred while
the test is running names1,
106 // If new MBean (e.g. Graal MBean) is registred while
the test is running mbeans1,
registred -> registered
',' after "running"
Just wondering how you chose 10 as the number of retries. Seems
excessive. Shouldn't the problem turn up at most 1 time and therefore
only 1 retry is needed.
76 int counter = 0;
86 if (sameSize(names1, names2, names3) || counter++ >
MAX_RETRY_ATTEMPTS) {
The way the checks are done you will actually end up retrying
MAX_RETRY_ATTEMPTS+1 times. For example, if MAX_RETRY_ATTEMPTS is 1,
first time through the loop counter is 0 so a retry is allowed. Second
time through the loop counter is 1, so a retry is allowed again.
thanks,
Chris
On 4/18/20 11:30 AM, Daniil Titov wrote:
Please review the change that fixes the failure of
javax/management/generified/GenericTest.java and
javax/management/query/CustomQueryTest.java tests when Graal is on.
The tests checks that calls of management API are consistent and return the
same set of MBeans. However,
when Graal is on the Graal MBean might be registered between the calls that in
turn makes the results
inconsistent and the tests fail.
The fix makes the test aware that some MBean might be registered while the
checks run and if it happens the tests repeat the check.
Testing : Mach5 tests with Graal on and tier1-tier3 tests passed.
[1] http://cr.openjdk.java.net/~dtitov/8242239/webrev.01/
[2] https://bugs.openjdk.java.net/browse/JDK-8242239
Thanks,
Daniil
