3:09 a.m.
CLONE -make RecoveryManager restartable
---------------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.5.0
Reporter: Mauro Molinari
Assignee: Jonathan Halliday
Fix For: 4.6.0
Stopping and restarting the transaction manager inside JBossAS causes problems, because
the recovery system does not like to be restarted once it is stopped:
java.lang.IllegalThreadStateException
at java.lang.Thread.start(Thread.java:571)
at
com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.start(RecoveryManagerImple.java:236)
at
com.arjuna.ats.arjuna.recovery.RecoveryManager.startRecoveryManagerThread(RecoveryManager.java:226)
at
com.arjuna.ats.jbossatx.jts.TransactionManagerService.start(TransactionManagerService.java:285)
Options would seem to be disposing the static singleton _recoveryManager in
RecoveryManager and recreating it on the next start, effectively causing a new
RecoveryManagerImple to be instantiated, or keep the RecoveryManagerImple instance and
rework its impl so that the PeriodicRecovery _periodicRecovery is disposed and recreated
on restart.
Either one has slightly odd semantics as the PeriodicRecovery is a Thread (which can't
be restarted so has to be replaced) and also the object that has the module list and the
server socket, so disposal and/or recreation of this state will be needed on restart.
Maybe better to rename stop() to dispose() or something similarly final, to indicate the
semantics are 'throw this away and start again' rather than giving the impression
that stop/start == suspend/resume which is misleading.
--
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
3:13 a.m.
New subject: [JBoss JIRA] Updated: (JBTM-535) CLONE -make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Mauro Molinari updated JBTM-535:
--------------------------------
Fix Version/s: (was: 4.6.0)
Affects Version/s: 4.6.1
(was: 4.5.0)
Description:
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
was:
Stopping and restarting the transaction manager inside JBossAS causes problems, because
the recovery system does not like to be restarted once it is stopped:
java.lang.IllegalThreadStateException
at java.lang.Thread.start(Thread.java:571)
at
com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.start(RecoveryManagerImple.java:236)
at
com.arjuna.ats.arjuna.recovery.RecoveryManager.startRecoveryManagerThread(RecoveryManager.java:226)
at
com.arjuna.ats.jbossatx.jts.TransactionManagerService.start(TransactionManagerService.java:285)
Options would seem to be disposing the static singleton _recoveryManager in
RecoveryManager and recreating it on the next start, effectively causing a new
RecoveryManagerImple to be instantiated, or keep the RecoveryManagerImple instance and
rework its impl so that the PeriodicRecovery _periodicRecovery is disposed and recreated
on restart.
Either one has slightly odd semantics as the PeriodicRecovery is a Thread (which can't
be restarted so has to be replaced) and also the object that has the module list and the
server socket, so disposal and/or recreation of this state will be needed on restart.
Maybe better to rename stop() to dispose() or something similarly final, to indicate the
semantics are 'throw this away and start again' rather than giving the impression
that stop/start == suspend/resume which is misleading.
CLONE -make RecoveryManager restartable
---------------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Jonathan Halliday
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
--
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
4 a.m.
New subject: [JBoss JIRA] Updated: (JBTM-535) CLONE -make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Mauro Molinari updated JBTM-535:
--------------------------------
Description:
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
was:
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
CLONE -make RecoveryManager restartable
---------------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Jonathan Halliday
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
--
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
4:59 a.m.
New subject: [JBoss JIRA] Updated: (JBTM-535) CLONE -make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Mauro Molinari updated JBTM-535:
--------------------------------
Parent: JBTM-468
Issue Type: Sub-task (was: Feature Request)
CLONE -make RecoveryManager restartable
---------------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Jonathan Halliday
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
--
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
8:19 a.m.
New subject: [JBoss JIRA] Updated: (JBTM-535) make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Mark Little updated JBTM-535:
-----------------------------
Summary: make RecoveryManager restartable (was: CLONE -make RecoveryManager
restartable)
make RecoveryManager restartable
--------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Jonathan Halliday
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
--
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
8:21 a.m.
New subject: [JBoss JIRA] Assigned: (JBTM-535) make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Mark Little reassigned JBTM-535:
--------------------------------
Assignee: Mark Little (was: Jonathan Halliday)
make RecoveryManager restartable
--------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Mark Little
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
--
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
9:05 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-535) make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Mauro Molinari commented on JBTM-535:
-------------------------------------
Another thought about the Listener.finalize() method: it is useless also because if the
Listener is running, it can't be finalized, so finalize() will never be called.
Viceversa, if finalize() is called it means that the listener has already been stopped, so
its finalize() implementation is useless... am I wrong?
make RecoveryManager restartable
--------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Mark Little
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
--
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
4:56 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-535) make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Mauro Molinari commented on JBTM-535:
-------------------------------------
Could this be targetted for 4.7.0? Resolution should be quite straightforward...
Thanks in advance.
make RecoveryManager restartable
--------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Mark Little
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
--
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
7:23 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-535) make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Mauro Molinari commented on JBTM-535:
-------------------------------------
Given that right now this problem is causing a memory leak whenever JBossJTA is restarted,
any thought on a candidate target release?
Thanks in advance.
make RecoveryManager restartable
--------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Mark Little
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
--
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
6:41 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-535) make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Andrew Dinn commented on JBTM-535:
----------------------------------
Hi Mauro,
I am fixing this as part of JBTM-569. I have a fix almost ready to commit so the problem
will be resolved by TS 4.8. I'll link this issue accordingly.
make RecoveryManager restartable
--------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Mark Little
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
--
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
10:53 a.m.
New subject: [JBoss JIRA] Commented: (JBTM-535) make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Andrew Dinn commented on JBTM-535:
----------------------------------
The listener thread is now shut down cleanly thanks to JBTM-569. Note that any active
Connection threads spawned by the listener are also shut down causing the socket on the
client end to be closed.
make RecoveryManager restartable
--------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Mark Little
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
--
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
10:55 a.m.
New subject: [JBoss JIRA] Assigned: (JBTM-535) make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Andrew Dinn reassigned JBTM-535:
--------------------------------
Assignee: Andrew Dinn (was: Mark Little)
make RecoveryManager restartable
--------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Andrew Dinn
Fix For: 4.8.0
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
--
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
10:55 a.m.
New subject: [JBoss JIRA] Closed: (JBTM-535) make RecoveryManager restartable
[
https://jira.jboss.org/jira/browse/JBTM-535?page=com.atlassian.jira.plugi...
]
Andrew Dinn closed JBTM-535.
----------------------------
Fix Version/s: 4.8.0
Resolution: Done
make RecoveryManager restartable
--------------------------------
Key: JBTM-535
URL: https://jira.jboss.org/jira/browse/JBTM-535
Project: JBoss Transaction Manager
Issue Type: Sub-task
Security Level: Public(Everyone can see)
Components: Application Server Integration, Recovery
Affects Versions: 4.6.1
Reporter: Mauro Molinari
Assignee: Andrew Dinn
Fix For: 4.8.0
Issue JBTM-468 is not completely solved.
com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery in its shutdown(boolean) method
does not stop the _listener, so a call to _listener.stopListener() should be added to it.
Otherwise the listener is never stopped and this can cause a leak if the JVM does not
terminate between restarts.
Moreover, as Listener threads are always started as daemon threads, I think
com.arjuna.ats.internal.arjuna.recovery.Listener.finalize() is quite useless: if the JVM
is terminating, the thread is stopped because it's a daemon thread, while in case of
restart the Listener is certainly stopped by the restart process (bugs permitting). As it
is right now, that finalize() method just causes useless GC overhead.
--
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
5427
days inactive
5499
days old
jbossts-issues@lists.jboss.org
12 comments
3 participants
participants (3)
-
Andrew Dinn (JIRA) -
Mark Little (JIRA)
-
Mauro Molinari (JIRA)