On Wed, 8 Feb 2023 11:57:21 GMT, Kevin Walls <[email protected]> wrote:
> 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.
Marked as reviewed by cjplummer (Reviewer).
-------------
PR: https://git.openjdk.org/jdk/pull/12472
