[
https://jira.jboss.org/jira/browse/JBTM-464?page=com.atlassian.jira.plugi...
]
Mark Little updated JBTM-464:
-----------------------------
Summary: Provide a way to dispose the ShutdownHook registered by TxControl (was:
Provide a way to dispose the TxControl)
This has nothing to do with "disposing" of TxControl, which wouldn't make
sense anyway. I have updated the title accordingly.
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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira