[
https://issues.apache.org/jira/browse/ARTEMIS-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Nigro updated ARTEMIS-2958:
-------------------------------------
Component/s: JMX
Broker
> Timed out waiting for pool slow down backup restart on failback
> ---------------------------------------------------------------
>
> Key: ARTEMIS-2958
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2958
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, JMX
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Minor
>
> The changes on ARTEMIS-2823 have caused to await AMQ thread pool on server
> stop to be moved after {{callDeActiveCallbacks()}} and the changes on
> ARTEMIS-2838 to
> {{server.getServer().getManagementService().unregisterHawtioSecurity()}} on
> {{callDeActiveCallbacks()}}: it means that on server restart, if any task is
> pending on the thread pool stop, the thread pool wouldn't let a start to
> activate JMX again for the default 10 seconds required to force a pool
> shutdown.
> The issue that was causing the thread pool to be blocked randomly awaiting an
> executing task was present by long time, but the unavailability of JMX
> introduced by the mentioned JIRAs has caused some random failures on
> {{org.apache.activemq.artemis.tests.smoke.jmxfailback.JmxFailbackTest#testFailbackOnJMX}}.
> This test check for 5 seconds the availability of backup JMX connection
> during a backup restart (on failback)) ie {{Wait.assertTrue(() ->
> testConnection(url2, objectNameBuilder2), 5_000, 100);}}: given that the
> default thread pool await time is 10 seconds, a longer thread pool stop will
> make the test to fail.
> It's important to investigate what is causing the global thread pool of the
> backup server on failback to not stop immediately.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
