November 2009 - jbossts-issues - Jboss List Archives

[JBoss JIRA] Closed: (JBTM-137) JTS PropagationContextManager does too much

by Mark Little (JIRA)

[ https://jira.jboss.org/jira/browse/JBTM-137?page=com.atlassian.jira.plugi... ] Mark Little closed JBTM-137. ---------------------------- Resolution: Out of Date > JTS PropagationContextManager does too much > ------------------------------------------- > > Key: JBTM-137 > URL: https://jira.jboss.org/jira/browse/JBTM-137 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: JTS > Affects Versions: 4.2.1 > Reporter: Mark Little > Assignee: Mark Little > Fix For: future > > > We should only need to send a reference to the current transaction and not the full context. Also means we don't need to do interposition, just resume. -- 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, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBTM-234) setRollbackOnly consistency

by Mark Little (JIRA)

setRollbackOnly consistency --------------------------- Key: JBTM-234 URL: http://jira.jboss.com/jira/browse/JBTM-234 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP4 Reporter: Mark Little Assigned To: Mark Little Priority: Optional OTS does not let you call rollback-only if the state of the transaction is not active. JTA doesn't make it clear whether or not that is an error. That makes it implementation dependent. At the moment both of our JTA implementations mask this issue. AS appears to not expect an exception from setRollbackOnly either, but that's may cause an issue if someone uses a different JTA. -- 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

15 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-592) Add fallback for Utility::hostInetAddr()

by Jesper Pedersen (JIRA)

Add fallback for Utility::hostInetAddr() ---------------------------------------- Key: JBTM-592 URL: https://jira.jboss.org/jira/browse/JBTM-592 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Common Affects Versions: 4.6.1 Reporter: Jesper Pedersen Priority: Minor If a host has a misconfigured hostname Utility::hostInetAddr() fails with an UnknownHostException. An extra try could be made after logging a warning about the failed InetAddress.getLocalHost() using InetAddress.getByName(null) - e.g. try { addr = InetAddress.getLocalHost(); } catch (UnknownHostException uhe) { log.warn("Unable to use InetAddress.getLocalHost() to resolve address"); addr = InetAddress.getByName(null); } -- 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, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-593) read-only optimization in configuration should point general second phase instead of second phase abort.

by Vicky Kak (JIRA)

read-only optimization in configuration should point general second phase instead of second phase abort. -------------------------------------------------------------------------------------------------------- Key: JBTM-593 URL: https://jira.jboss.org/jira/browse/JBTM-593 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Vicky Kak Assignee: Mark Little I can see the read-only optimization details provided in the docs as "Enable or disable read-only optimization for the second phase abort." http://www.jboss.org/jbosstm/docs/4.2.3/manuals/html/core/ProgrammersGuid... The read-only optimization should work for second phase in general, irrespective of it being rollback/commit. The abort in "second phase abort." seems to be pointing to the rollback process in second phase. There should be a change of "second phase abort" to "second phase" -- 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, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBTM-299) Xid pack should ignore trailing zeros

by Mark Little (JIRA)

Xid pack should ignore trailing zeros ------------------------------------- Key: JBTM-299 URL: http://jira.jboss.com/jira/browse/JBTM-299 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTA Implementation Affects Versions: 4.2.3.SP6 Reporter: Mark Little Assigned To: Mark Little Priority: Minor Fix For: 4.6 It packs the whole array even if most of it is zeros. -- 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

15 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-650) Investigate periodic NPE on getting RootPOA

by Mark Little (JIRA)

Investigate periodic NPE on getting RootPOA ------------------------------------------- Key: JBTM-650 URL: https://jira.jboss.org/jira/browse/JBTM-650 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: JTS Reporter: Mark Little Assignee: Mark Little Fix For: 4.10.0 Periodically I see: 2009-11-09 13:29:36,378 [main] WARN com.arjuna.ats.jts.logging.loggerI18N - [com.arjuna.ats.internal.jts.orbspecific.jacor b.recoverycoordinators.JacOrbRCServiceInit_1] [com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRC ServiceInit_1] - Failed to create poa for recoverycoordinators java.lang.NullPointerException at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.getRCPOA(JacOrbRCService Init.java:213) at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCS erviceInit.java:239) at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:127) at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:79) at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.<init>(RecActivatorLoader.java:58) at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:144) at com.arjuna.ats.arjuna.recovery.RecoveryManager.<init>(RecoveryManager.java:521) at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:136) at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:117) at com.arjuna.ats.arjuna.recovery.RecoveryManager.main(RecoveryManager.java:492) 2009-11-09 13:29:36,381 [main] WARN com.arjuna.ats.jts.logging.loggerI18N - [com.arjuna.ats.internal.jts.orbspecific.jacor b.recoverycoordinators.JacOrbRCServiceInit_3] [com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRC ServiceInit_3] - JacOrbRCServiceInit - Failed to start RC service java.lang.NullPointerException at com.arjuna.ats.internal.jts.orbspecific.jacorb.recoverycoordinators.JacOrbRCServiceInit.startRCservice(JacOrbRCS erviceInit.java:249) at com.arjuna.ats.internal.jts.orbspecific.recovery.RecoveryEnablement.startRCservice(RecoveryEnablement.java:127) at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.startRecoveryActivators(RecActivatorLoader.java:79) at com.arjuna.ats.internal.arjuna.recovery.RecActivatorLoader.<init>(RecActivatorLoader.java:58) at com.arjuna.ats.internal.arjuna.recovery.RecoveryManagerImple.<init>(RecoveryManagerImple.java:144) at com.arjuna.ats.arjuna.recovery.RecoveryManager.<init>(RecoveryManager.java:521) at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:136) at com.arjuna.ats.arjuna.recovery.RecoveryManager.manager(RecoveryManager.java:117) from some of the crashrec QE (specifically batch 12). The tests still complete, so maybe this is over jealous warnings or the lack of an if/then clause. -- 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, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-652) XAResourceSetup returns wrong type in JTS

by Mark Little (JIRA)

XAResourceSetup returns wrong type in JTS ----------------------------------------- Key: JBTM-652 URL: https://jira.jboss.org/jira/browse/JBTM-652 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.6.1.CP03 Reporter: Mark Little Assignee: Mark Little Fix For: 4.6.1.CP04 The XAResourceSetup class (part of Gandiva) createVoid method returns an instance of ExtendedResourceRecord instead of an XAResourceRecord. I haven't tested this hyopthesis yet, but I suspect that we fail silently during transaction initiated recovery and then succeed when recovery is driven from the participant. Thus the workaround for this is to do nothing, as the impact is "only" a delay on recovery. But I need to double check that hypothesis. -- 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, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JBTM-639) Move private AbstractRecords

by Mark Little (JIRA)

Move private AbstractRecords ---------------------------- Key: JBTM-639 URL: https://jira.jboss.org/jira/browse/JBTM-639 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Core Reporter: Mark Little Assignee: Mark Little Fix For: 4.9.0 With the removal of Gandiva we're breaking a lot of existing interfaces anyway. There are some AbstractRecord implementations that no one should be using directly and I want to move them to the internal package. -- 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, 1 month

1
4
0 / 0

[JBoss JIRA] Created: (JBTM-647) Move LockList and friends to private (if possible).

by Mark Little (JIRA)

Move LockList and friends to private (if possible). --------------------------------------------------- Key: JBTM-647 URL: https://jira.jboss.org/jira/browse/JBTM-647 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Reporter: Mark Little Assignee: Mark Little Fix For: 5.0.0 -- 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, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JBTM-636) Need a way of determining the age of a transaction post prepare

by Michael Musgrove (JIRA)

Need a way of determining the age of a transaction post prepare --------------------------------------------------------------- Key: JBTM-636 URL: https://jira.jboss.org/jira/browse/JBTM-636 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.8.0 Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Minor Fix For: 5.0.0 The management tools for JBossTM need to be able to display the age of a transaction post prepare stage to enable monitoring of 'wedged' transactions. This information is currently not available. -- 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, 1 month

3
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues November 2009