RFR: 8255031 : Update java/util/prefs/AddNodeChangeListener.java to report more failure info
Brent Christian
bchristi at openjdk.java.net
Wed Oct 21 17:49:20 UTC 2020
On Tue, 20 Oct 2020 23:25:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:
>> Hi,
>>
>> The java/util/prefs/AddNodeChangeListener.java test fails once in a while in the automated test system. Previous failures were traced to machine configuration errors, but that does not appear to be the case this time.
>>
>> My efforts to reproduce this failure have been unsuccessful. The only useful information I've gleaned so far from the test failure logs is that the overall duration for running tier1 is longer than usual when the test failure happens.
>>
>> I would like to make the following updates to the test, in hopes of learning more if and when this test fails again:
>>
>> * fail faster, to report if it is addNode() or removeNode() that is failing
>> * make multiple attempts to sleep+check the NodeChangeListener. (If the test fails after a single sleep, but passes after waiting longer, maybe we just need to sleep for longer to account for the occasional slower tier1 test run).
>> * a few indentations fixes
>>
>> Thanks,
>> -Brent
>
> test/jdk/java/util/prefs/AddNodeChangeListener.java line 65:
>
>> 63:
>> 64: for (int i = 0; i < SLEEP_ITRS; i++) {
>> 65: Thread.sleep(3000);
>
> Would there be any value in printing the iteration number here and in the analogous location in removeNode() in case the test times out?
That's a pretty good idea. In theory, there should be a maximum of 90s total of sleeping, and enough time for the test to complete within the default timeout of 2m. But AFAICT in the failure case, the test takes longer to run, so maybe it could timeout in that case. If this failure eventually shows up again, it would be best to have at least *some* new output to show for it. :)
-------------
PR: https://git.openjdk.java.net/jdk/pull/773
More information about the core-libs-dev
mailing list