[jbossts-issues] [JBoss JIRA] Updated: (JBTM-464) Provide a way to dispose the ShutdownHook registered by TxControl

Provide a way to dispose the ShutdownHook registered by TxControl ----------------------------------------------------------------- Key: JBTM-464 URL: https://jira.jboss.org/jira/browse/JBTM-464 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public(Everyone can see) Components: Documentation, Transaction Core Affects Versions: 4.4.0.GA Reporter: Mauro Molinari Assignee: Mark Little We're using JBossJTA embedded in our webapp, so it is deployed with our webapp. In this context when the webapp is stopped we need to shutdown JBossJTA completely. However, there are some leaks that are causing the webapp classloader not to be garbage collectable. One is addressed by JBTM-462. Another is caused by com.arjuna.ats.arjuna.coordinator.TxControl. In fact: - a shutdown hook is registered by TxControl and can't be unregistered - that shutdown hook calls finalize() on the TransactionStatusManager which is responsible of stopping the recovery listener Apart from the fact that it sounds quite strange that a finalize method is used to shutdown something, the problem is that: - the TransactionStatusManager is a field of TxControl with package visibility, so there's no way to access it from outside the TxControl and/or another class of the same package - TxControl does not have any public shutdown/dispose static method: this method shut unregister the shutdown hook and call TransactionStatusManager.finalize() - even if com.arjuna.ats.internal.arjuna.recovery.Listener.stopListener() calls interrupt() to stop the recovery listener thread, in my tests I observed that the thread is not actually interrupted (it seems that java.net.ServerSocket.accept() doesn't honour the interrupt method by interrupting itself...), so if the property com.arjuna.ats.internal.arjuna.recovery.listener.timeoutsocket in jbossjta-properties.xml is set to NO or is not set (which seemed to be the default in my configuration...), the recovery listener thread waits undefinitely and never stops, even if Listener.stopListener() is called