August 2009 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Created: (JBTM-607) fix CLF logger selection

by Jonathan Halliday (JIRA)

fix CLF logger selection ------------------------ Key: JBTM-607 URL: https://jira.jboss.org/jira/browse/JBTM-607 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Common Affects Versions: 4.7.0 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.8.0 CLF does not init the right underlying logger, always uses log4j instead. Fix and clean up obsolete loggers whist we're at it. -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-298) There is no way for recovery through JCA to indicate temporary failure to recover

by Mark Little (JIRA)

There is no way for recovery through JCA to indicate temporary failure to recover --------------------------------------------------------------------------------- Key: JBTM-298 URL: http://jira.jboss.com/jira/browse/JBTM-298 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP5 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.4 This means client-driven recovery sees a failure to recover and doesn't try again. We should give a "try again later" option (XA_RETRY). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
5
0 / 0

[JBoss JIRA] Created: (JBTM-226) Possible race condition between top-down and bottom-up recovery

by Mark Little (JIRA)

Possible race condition between top-down and bottom-up recovery --------------------------------------------------------------- Key: JBTM-226 URL: http://jira.jboss.com/jira/browse/JBTM-226 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP4 Environment: Mac OS X, JDK 1.4.2. Reporter: Mark Little Assigned To: Mark Little Priority: Critical In local JTA recovery for non-serializable XAResources, the XAResourceRecovery implementation is needed to obtain a new XAResource. If a new resource isn't obtained (because the XAResourceRecovery instances haven't all been triggered yet), top-down recovery retries on subsequent recovery sweeps. Meanwhile, bottom up recovery can kick in and use an XAResource from a XAResourceRecovery that is now available and fail to locate any information on the transaction that will drive it top-down. Upon failing to find the transaction, it uses presumed abort and rolls back the instance, when in fact it should wait and commit it. But it doesn't do that until several phases have passed, and in which case most of the time top-down recovery will have re-run, found the XAResource and committed the transaction. I'm fairly sure this is a race condition and does exist, but am still checking. Work around exists at the moment though. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

3
9
0 / 0

[JBoss JIRA] Created: (JBTM-606) OracleXARecovery does not support encrypted passwords

by Tyronne Wickramarathne (JIRA)

OracleXARecovery does not support encrypted passwords ----------------------------------------------------- Key: JBTM-606 URL: https://jira.jboss.org/jira/browse/JBTM-606 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Recovery Affects Versions: 4.2.3.CP05 Environment: JBoss-EAP-4.3_CP06 Reporter: Tyronne Wickramarathne OracleXARecovery doesn't support encrypted passwords at present. There's a request to accommodate this feature on the upcoming release. -- 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

14 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBTM-602) XA recovery fails to span XAResources

by Jonathan Halliday (JIRA)

XA recovery fails to span XAResources ------------------------------------- Key: JBTM-602 URL: https://jira.jboss.org/jira/browse/JBTM-602 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Application Server Integration, Recovery Affects Versions: 4.7.0, 4.6.1, 4.2.3.CP05 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.2.3.SP8, 4.2.3.CP06, 4.8.0, 4.6.1.CP02 XARecoveryModule runs scans against XAResource and holds the results. On the next invocation it compares the new and old scan results to determine which xids are still outstanding, assumes they are in need of recovery and deals with them. This two stage process is to avoid rolling back tx branches that are still live and just between the prepare/[commit|rollback] phases. The idea, whilst good in principle, is flawed in execution. It operates on the assumption that consecutive scans against a given RM will use the same (as defined by hashcode/equals semantics) XAResource. This assumption fails where a different connection to the same RM is used and the driver is implemented such that the XAResource identity is tied to the [XA]Connection. This occurs particularly with AppServerJDBCXARecovery, which uses a fresh connection on each pass to ensure that recovery scans don't blow up because of stale connections, such as occur when a db bounces but the AS keeps running. More generally, the contract between XARecoveryModule, the XAResourceRecovery impls and XAResourceRecoveryHelper impls needs to be flexible enough to accommodate this. The upshot of this is that XARecoveryModule can't assume a given RM will be represented by the same XAResource on different passes and must therefore cache Xids between passes using a different structure. It's actually not required to hold the XAResource itself between passes, since the resource for the current pass will always be available. Thus keeping only the Xids from the previous scan would seem best. -- 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

14 years, 8 months

3
4
0 / 0

[JBoss JIRA] Created: (JBTM-604) support building 4.6.1 CPs on java 1.6

by Jonathan Halliday (JIRA)

support building 4.6.1 CPs on java 1.6 -------------------------------------- Key: JBTM-604 URL: https://jira.jboss.org/jira/browse/JBTM-604 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Application Server Integration, Build System, Release Process Affects Versions: 4.6.1.CP01 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.6.1.CP02 JBossTS 4.6.1 builds on 1.5. It won't build on 1.6 because it does not have JDBC4 support (JBTM-419) However, EAP5 builds mainly on 1.6 and life would be easier if TS CP releases could link against it rather than requiring a separate AS 1.5 build. Therefore, support building on 1.6 but skip the JDBC module for such builds - it's not used in the EAP anyhow. -- 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

14 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBTM-603) RegistrarImple use non-treadsafe data structure

by Jonathan Halliday (JIRA)

RegistrarImple use non-treadsafe data structure ----------------------------------------------- Key: JBTM-603 URL: https://jira.jboss.org/jira/browse/JBTM-603 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: XTS Affects Versions: 4.6.1 Reporter: Jonathan Halliday Assignee: Jonathan Halliday Fix For: 4.6.1.CP01 Using a HashMap instead of a ConcurrentHashMap causes bad things to happen every now and then. -- 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

14 years, 8 months

2
4
0 / 0

[JBoss JIRA] Updated: (JBTM-44) Transaction bridging

by Jonathan Halliday (JIRA)

[ https://jira.jboss.org/jira/browse/JBTM-44?page=com.atlassian.jira.plugin... ] Jonathan Halliday updated JBTM-44: ---------------------------------- Fix Version/s: 4.9 (was: 4.8.0) > Transaction bridging > -------------------- > > Key: JBTM-44 > URL: https://jira.jboss.org/jira/browse/JBTM-44 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTA, JTS, XTS > Reporter: Mark Little > Assignee: Jonathan Halliday > Priority: Critical > Fix For: 4.9 > > Attachments: jbossxts-bridge.zip > > -- 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

14 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-554) Testsuite - fluctuant org.omg.CORBA.OBJECT_NOT_EXIST: Server-side Exception errors on RHEL4 and Sun/IBM jdk1.5

by Ivo Studensky (JIRA)

Testsuite - fluctuant org.omg.CORBA.OBJECT_NOT_EXIST: Server-side Exception errors on RHEL4 and Sun/IBM jdk1.5 -------------------------------------------------------------------------------------------------------------- Key: JBTM-554 URL: https://jira.jboss.org/jira/browse/JBTM-554 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Testing Affects Versions: 4.6.1 Environment: RHEL4 x86_64 + java15_x86_64 and RHEL4_x86 + ibm15 Reporter: Ivo Studensky An error occurs on the combination of RHEL4 and Sun/IBM jdk1.5 in the otsserver test group. Sometimes there are 2 errors, sometimes only 1 error occurs. Error messages from the log are here: Client14.Worker.run: org.omg.CORBA.OBJECT_NOT_EXIST: Server-side Exception: vmcid: 0x0 minor code: 0 completed: No org.omg.CORBA.OBJECT_NOT_EXIST: Server-side Exception: vmcid: 0x0 minor code: 0 completed: No at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.jacorb.orb.SystemExceptionHelper.read(Unknown Source) at org.jacorb.orb.ReplyReceiver.getReply(Unknown Source) at org.jacorb.orb.Delegate.invoke_internal(Unknown Source) at org.jacorb.orb.Delegate.invoke(Unknown Source) at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:457) at org.omg.CosTransactions._ControlStub.get_terminator(_ControlStub.java:32) at org.jboss.jbossts.qa.OTSServerClients.Client14$Worker.run(Client14.java:164) [jacorb.poa] INFO : POA RootPOA destroyed java.io.FileNotFoundException: ServerIORs (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:106) at java.io.FileInputStream.<init>(FileInputStream.java:66) at org.jboss.jbossts.qa.Utils.FileServerIORStore.removeIOR(FileServerIORStore.java:69) at org.jboss.jbossts.qa.Utils.ServerIORStore.removeIOR(ServerIORStore.java:47) at org.jboss.jbossts.qa.Utils.RemoveServerIORStore.main(RemoveServerIORStore.java:42) Error logs on Hudson: http://hudson.qa.jboss.com/hudson/view/JBossTS/job/jbossts-testsuite-matr... http://hudson.qa.jboss.com/hudson/view/JBossTS/job/jbossts-testsuite-matr... http://hudson.qa.jboss.com/hudson/view/JBossTS/job/jbossts-testsuite-matr... Affected Hudson jobs: http://hudson.qa.jboss.com/hudson/view/JBossTS/job/jbossts-testsuite-matr... 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

14 years, 8 months

2
5
0 / 0

[JBoss JIRA] Created: (JBTM-601) LocalJunitRunner shoudl not poll server forever

by Andrew Dinn (JIRA)

LocalJunitRunner shoudl not poll server forever ----------------------------------------------- Key: JBTM-601 URL: https://jira.jboss.org/jira/browse/JBTM-601 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Testing Affects Versions: 4.6.0 Reporter: Andrew Dinn Assignee: Andrew Dinn Fix For: 4.6.1.CP01, 4.8.0 The LocalJUnitRunner class is used to automate XTS unit testing. It sends a request to an HTTP servlet in a spawned AS and then polls the servlet waiting for the test results to come back. The poll loop waits for a result containing the keyword "finished". This means it will run forever if one of the unit tests hangs. The poll loop should have some way of timing out, e.g. by limiting the number of times it will loop. -- 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

14 years, 8 months

3
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues August 2009