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.
This pull request has now been integrated.
Changeset: 1c7b09bc
Author: Kevin Walls <[email protected]>
URL:
https://git.openjdk.org/jdk/commit/1c7b09bc23ac37f83b9043de35b71bea7e814da5
Stats: 16 lines in 2 files changed: 6 ins; 2 del; 8 mod
8302069:
javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java update
Reviewed-by: cjplummer, amenkov
-------------
PR: https://git.openjdk.org/jdk/pull/12472
