[JBoss JIRA] Created: (JBTM-535) CLONE -make RecoveryManager restartable
by Mauro Molinari (JIRA)
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
15 years, 5 months
[JBoss JIRA] Created: (JBTM-503) Shutdown the ExpiredEntryMonitor when stopping the RecoveryManager
by Mauro Molinari (JIRA)
Shutdown the ExpiredEntryMonitor when stopping the RecoveryManager
------------------------------------------------------------------
Key: JBTM-503
URL: https://jira.jboss.org/jira/browse/JBTM-503
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Recovery
Affects Versions: 4.5
Environment: Tomcat + Spring + DBCP + JBossJTA
Reporter: Mauro Molinari
When the recovery manager is started, the implementation RecoveryManagerImple starts the ExpiredEntryMonitor.
When you stop the recovery manager, however, the ExpiredEntryMonitor is not shut down.
On line 250 of com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple there's the line ExpiredEntryMonitor.shutdown() commented out, with a "TODO why?" comment immediately before.
I don't know exactly what should be the lifecylce of ExpiredEntryMonitor versus that of RecoveryManagerImple, however I think that one of the following should happen:
- ExpiredEntryMonitor is started when RecoveryManagerImple is started (rather than constructed), so that it is shut down when the RecoveryManagerImple is stopped
OTHERWISE
- RecoveryManagerImple provides a way to "dispose" or "disable" it and this includes the shutdown of ExpiredEntryMonitor
OTHERWISE
- it is documented that stopping the recovery manager needs the ExpiredEntryMonitor to be stopped too: however, please consider that com.arjuna.ats.internal.arjuna.recovery.ExpiredEntryMonitor.shutdown() throws a NullPointerException if called while the ExpiredEntryMonitor has not been started before and there is no public method to test if it has been started or not; so if I need to write some code that stops the ExpiredEntryMonitor (without knowing if it has been started or not) I have to write some ugly code like:
{code:java}
try
{
ExpiredEntryMonitor.shutdown();
}
catch(final NullPointerException e)
{
// ExpiredEntryMonitor had not been started
}
{code}
--
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
15 years, 5 months
[JBoss JIRA] Created: (JBTM-574) update build system
by Jonathan Halliday (JIRA)
update build system
-------------------
Key: JBTM-574
URL: https://jira.jboss.org/jira/browse/JBTM-574
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Build System
Affects Versions: 4.7.0
Reporter: Jonathan Halliday
Assignee: Jonathan Halliday
Fix For: 4.8.0
The ant build scripts for Arjuna[Core|JTA|JTS] are ancient, contain a lot of unnecessary complexity and duplication and generally offend and upset me. Their days are numbered.
Rework the build system to:
- be easier to read and modify
- use 'modern' ant features such as import and macrodef to reduce duplication, exploiting the regularity of the module structure in our layout.
- maintain the same top level target names and more or less the same results, so scripts that use it don't have to change.
- make the module dependencies clearer, as a prelude to using some form of dependency management (e.g. ivy/maven)
--
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
15 years, 5 months
build scripts
by Jonathan Halliday
I'm rewriting the build system for core/jta/jts/atsintegration.
If you use anything other than the top level targets 'jta',
'jts', 'jbossjta' and 'jbossjts' with default options, now
would be a good time to let me know. Pretty much everything
else will change or vanish.
Jonathan.
15 years, 6 months
[JBoss JIRA] Created: (JBTM-550) LocalTestManager: Incorrect url to test definition XMLs on MS Windows
by Ivo Studensky (JIRA)
LocalTestManager: Incorrect url to test definition XMLs on MS Windows
---------------------------------------------------------------------
Key: JBTM-550
URL: https://jira.jboss.org/jira/browse/JBTM-550
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Testing
Affects Versions: 4.6.1
Environment: MS Windows 2003 Server, Sun JDK 1.5, Apache Ant 1.6.5
Reporter: Ivo Studensky
An error occured in JBossTS testsuite executed on Windows. See log snippet:
Caused by: java.net.UnknownHostException: C
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)
at java.net.Socket.connect(Socket.java:520)
at java.net.Socket.connect(Socket.java:470)
at sun.net.NetworkClient.doConnect(NetworkClient.java:157)
at sun.net.NetworkClient.openServer(NetworkClient.java:118)
at sun.net.ftp.FtpClient.openServer(FtpClient.java:488)
at sun.net.ftp.FtpClient.openServer(FtpClient.java:475)
at sun.net.www.protocol.ftp.FtpURLConnection.connect(FtpURLConnection.java:270)
at sun.net.www.protocol.ftp.FtpURLConnection.getInputStream(FtpURLConnection.java:352)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:973)
at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:184)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:798)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:489)
at org.jdom.input.SAXBuilder.build(SAXBuilder.java:847)
at org.jboss.dtf.testframework.coordinator2.TestDefinitionRepository.parse(TestDefinitionRepository.java:62)
at org.jboss.dtf.testframework.coordinator2.TestDefinitionRepository.<init>(TestDefinitionRepository.java:52)
at org.jboss.dtf.testframework.local.LocalTestManager.getInstance(LocalTestManager.java:92)
at org.jboss.dtf.testframework.local.JUnitTestSuite.setup(JUnitTestSuite.java:104)
It seems there is an problem with creating correct URL for Windows to the configuration XMLs in org.jboss.dtf.testframework.local.LocalTestManager.getInstance(LocalTestManager.java:92).
See Hudson job: http://hudson.qa.jboss.com/hudson/view/JBossTS/job/jbossts-testsuite-matr...
--
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
15 years, 6 months
[JBoss JIRA] Created: (JBTM-541) Enhance support for MySQL XA connections
by mohankishore (JIRA)
Enhance support for MySQL XA connections
----------------------------------------
Key: JBTM-541
URL: https://jira.jboss.org/jira/browse/JBTM-541
Project: JBoss Transaction Manager
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: JTA
Affects Versions: 4.6.1
Reporter: mohankishore
Fix For: 4.6.1.CP01
As generally accepted, the MySQL support for XA is somewhat broken.
If you do the following:
- begin a transaction
- get an XAConnection from MySQL,
- get a connection from the XAC
- do some operations,
- close the connection
- get another connection from XAC
- try to do some operations -> MYSQL throws an exception stating that it does not support a XA START RESUME
But, this leads to certain undesirable behavior inside the JBOSS JTA codebase. It is resulting in not calling XAC.close(). We are using a custom pool for limiting the number of XAConnections we create - which gets maxed out because of this. Am attaching a patch that seems to help out.
--
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
15 years, 6 months