NotifReconnectDeadlockTest.java has been problemlisted for a long time
(although 8042215 is the wrong bug id).
The originally reported problem ("No reconnection happened") cannot be
reproduced, although there are occasional failures when the test is run.
Those failures are more like the connection failures fixed in similar tests
(e.g. JDK-8227337), where:
java.rmi.NoSuchObjectException: no such object in table
..is reported, a startup issue, before the notification work, a failure to
connect:
at
java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
at NotifReconnectDeadlockTest.main(NotifReconnectDeadlockTest.java:88)
We should do something similar here, but not such that it affects the deadlock
timing. Increase serverTimeout, it needs a longer timeout to permit the
initial connect to work reliably (fails occasionally, particularly but not
exclusively on Windows debug builds). Not using the test library timeout
scaling here as the timeout has to be kept fairly short, to let the test
intentionally block the notification handler and try to cause the original
issue.
Additional prints to make the test logs hopefully easier to follow, and tried
to clarify a few comments that made no sense to me.
Passing on many runs on all platforms.
-------------
Commit messages:
- 8042596:
javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java No
reconnection happened
Changes: https://git.openjdk.org/jdk/pull/12472/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12472&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8302069
Stats: 16 lines in 2 files changed: 6 ins; 2 del; 8 mod
Patch: https://git.openjdk.org/jdk/pull/12472.diff
Fetch: git fetch https://git.openjdk.org/jdk pull/12472/head:pull/12472
PR: https://git.openjdk.org/jdk/pull/12472
