February 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1330) Support Last Logging Resource

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1330?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1330: -------------------------------- Priority: Major (was: Critical) > Support Last Logging Resource > ----------------------------- > > Key: JBTM-1330 > URL: https://issues.jboss.org/browse/JBTM-1330 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.0.M3 > > > Where you multiplex the users application table and the transaction log in the same JDBC local transaction. > LLR > === > xar1::prepare(); // sync 1 > ds1::insert(tmLog) ds1::commit() // sync 2 > xar1::commit(); // sync 3 > lazily remove (tmLog) // sync 4 > XA > == > xar1::prepare(); // sync 1 > xar2::prepare(); // sync 2 > tm::log() // sync 3 > xar1::commit() // sync 4 > xar2::commit() // sync 5 > (potentally lazily) remove (tmLog) // sync 6 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1399) CI cluster hostname issue

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1399?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1399: -------------------------------- Priority: Minor (was: Major) > CI cluster hostname issue > ------------------------- > > Key: JBTM-1399 > URL: https://issues.jboss.org/browse/JBTM-1399 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS, Testing > Reporter: Paul Robinson > Priority: Minor > > http://172.17.131.2/job/btny-pulls-narayana/283/ > {code} > Running com.hp.mwtests.ts.jts.participants.ExtendedResourceUnitTest > Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 11.426 sec <<< FAILURE! > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1481) Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1481?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1481: -------------------------------- Component/s: JTS Transaction Core > Transaction::commit on an transaction that the reaper has tried to rollback but has a wedged resource will not raise an exception > --------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-1481 > URL: https://issues.jboss.org/browse/JBTM-1481 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS, Transaction Core > Affects Versions: 4.6.1.CP13 > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 4.6.1.CP14, 4.16.7, 4.17.4, 5.0.0.M2 > > Attachments: JBTM-1481.patch, WedgedResourceDemonstrator.java > > > If you are getting a wedged resource. What then happens is that we interrupt the original reaper thread that is calling XAResource::rollback on the wedged resource which because you are using JacORB and have an in progress call will generate a null pointer exception when the thread is interrupted (you can see this in my attached log file, it prints a stack trace where the logging didn't do so before) which generates a org.omg.CORBA.TRANSACTION_ROLLEDBACK exception. > The problem is that after the reaper tries to rollback the transaction but stalls on a wedged resource, it is then possible for the app thread to unwedged and to do a JTA::commit() and not get an exception. Debugging through the code, it doesn't pose data integrity issues on the transaction as what is happening is that internally we are checking the status of the transaction: > ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:340 > And because the transaction is not RUNNING or ABORT_ONLY, we are: > ./ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java:398: > throw new INVALID_TRANSACTION(0, CompletionStatus.COMPLETED_NO) > Which is all good so far but then ends up in: > ./ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java:1425 > catch (INVALID_TRANSACTION e6) > { > /* > * In JTS/OTS we can indicate that something was terminated by another thread. > * JTA doesn't really prevent this, but ... > */ > > //throw new IllegalStateException( > // jtaLogger.loggerI18N.getString("com.arjuna.ats.internal.jta.transaction.jts.invalidtx2")); > } > Where it appears at some point we would have thrown an exception but decided to make the call that this was not valid anymore. > As I say, it doesn't pose data integrity implications to the specific transaction, but if your app thread unwedges and you then make a decision on the outcome of the transaction (send email, acknowledge success) then it would break the business rules of that application. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1330) Support Last Logging Resource

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1330?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1330: -------------------------------- Fix Version/s: (was: 4.17.4) > Support Last Logging Resource > ----------------------------- > > Key: JBTM-1330 > URL: https://issues.jboss.org/browse/JBTM-1330 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.0.0.M3 > > > Where you multiplex the users application table and the transaction log in the same JDBC local transaction. > LLR > === > xar1::prepare(); // sync 1 > ds1::insert(tmLog) ds1::commit() // sync 2 > xar1::commit(); // sync 3 > lazily remove (tmLog) // sync 4 > XA > == > xar1::prepare(); // sync 1 > xar2::prepare(); // sync 2 > tm::log() // sync 3 > xar1::commit() // sync 4 > xar2::commit() // sync 5 > (potentally lazily) remove (tmLog) // sync 6 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1359) Support HA RecoveryManager

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1359?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1359: -------------------------------- Fix Version/s: (was: 4.17.4) > Support HA RecoveryManager > -------------------------- > > Key: JBTM-1359 > URL: https://issues.jboss.org/browse/JBTM-1359 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.0.M3 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-312) Add clustering support

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-312?page=com.atlassian.jira.plugin.s... ] Tom Jenkinson updated JBTM-312: ------------------------------- Fix Version/s: (was: 4.17.4) > Add clustering support > ---------------------- > > Key: JBTM-312 > URL: https://issues.jboss.org/browse/JBTM-312 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: JTA, JTS, Recovery, Transaction Core, XTS > Affects Versions: 4.3.0.BETA2 > Reporter: Mark Little > Assignee: Tom Jenkinson > Fix For: 5.0.0.M3 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1482) If a naughty afterCompletion sync throws an exception, log the exception call stack

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1482?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1482: -------------------------------- Issue Type: Enhancement (was: Feature Request) > If a naughty afterCompletion sync throws an exception, log the exception call stack > ----------------------------------------------------------------------------------- > > Key: JBTM-1482 > URL: https://issues.jboss.org/browse/JBTM-1482 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Transaction Core > Reporter: Scott Marlow > Assignee: Tom Jenkinson > > Currently, when this happens with AS, I see: > {quote} > 2013-02-18 16:24:43,837|WARN |[com.arjuna.ats.jta]|(ThreadId: Transaction Reaper Worker 221)|ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.jboss.as.jpa.transaction.TransactionUtil$SessionSynchronization@634ef5a7 with exception: java.lang.NullPointerException > {quote} > From a related email conversation: > {quote} > Here's our Logger code: > @Message(id = 16029, value = "SynchronizationImple.afterCompletion - failed for {0} with exception", format = MESSAGE_FORMAT) > @LogMessage(level = WARN) > public void warn_resources_arjunacore_SynchronizationImple(String arg0, @Cause() Throwable arg1); > Here is where we call our logger: > jtaLogger.i18NLogger.warn_resources_arjunacore_SynchronizationImple(_theSynch.toString(), e); > Maybe the message should have the {1} in it, i.e. it change it like so: > "SynchronizationImple.afterCompletion - failed for {0} with exception {1}" > {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1444) Review the logging in XTS when WS-AT participants throw Exceptions in commit or rollback

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1444?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1444: -------------------------------- Issue Type: Enhancement (was: Feature Request) > Review the logging in XTS when WS-AT participants throw Exceptions in commit or rollback > ---------------------------------------------------------------------------------------- > > Key: JBTM-1444 > URL: https://issues.jboss.org/browse/JBTM-1444 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: XTS > Reporter: Paul Robinson > Labels: assign > Original Estimate: 1 day > Remaining Estimate: 1 day > > Check what happens when each possible Exception is thrown from a WS-AT participant's commit or Rollback method. > For each case consider whether enough logging is provided. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1445) Ensure chained exceptions are used throughout XTS

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1445?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1445: -------------------------------- Issue Type: Enhancement (was: Feature Request) > Ensure chained exceptions are used throughout XTS > ------------------------------------------------- > > Key: JBTM-1445 > URL: https://issues.jboss.org/browse/JBTM-1445 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: XTS > Reporter: Paul Robinson > Labels: assign > > There should be a way of automating this, or at least reliably searching for every occurrence. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-1459) Create a parallel version of beforeCompletion invocations

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1459?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1459: -------------------------------- Issue Type: Enhancement (was: Feature Request) > Create a parallel version of beforeCompletion invocations > --------------------------------------------------------- > > Key: JBTM-1459 > URL: https://issues.jboss.org/browse/JBTM-1459 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: JTA > Affects Versions: 4.17.3 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.0.Final > > Original Estimate: 6 hours > Remaining Estimate: 6 hours > > Some RM's do the bulk of there work in the beforeCompletion synchronisations so it would be beneficial to have an option for calling it asynchronously. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues February 2013