[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:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> 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
11 years, 7 months
[JBoss JIRA] (JBTM-1508) Improve the way 'default-context-propagation' is disabled in DisabledContextPropagationTests
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1508:
-----------------------------------
Summary: Improve the way 'default-context-propagation' is disabled in DisabledContextPropagationTests
Key: JBTM-1508
URL: https://issues.jboss.org/browse/JBTM-1508
Project: JBoss Transaction Manager
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Testing, XTS
Reporter: Paul Robinson
Assignee: Gytis Trikleris
Fix For: 5.0.0.M3
Currently we copy across a modified version of standalone-xts.xml. The problem is that this file needs to be kept in sync with the original.
The main problem is that these tests will fail every time an upstream change is made to standalone-xts.xml.
--
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
11 years, 7 months
[JBoss JIRA] (JBTM-1507) Review the TXBridge tests usage of Arquillian
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1507:
-----------------------------------
Summary: Review the TXBridge tests usage of Arquillian
Key: JBTM-1507
URL: https://issues.jboss.org/browse/JBTM-1507
Project: JBoss Transaction Manager
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Testing, TxBridge
Reporter: Paul Robinson
Assignee: Paul Robinson
Priority: Minor
Fix For: 5.0.0.M3
The TXBridge tests don;t seem to be using Arquillian correctly. There is a servlet that is invoked to do things inside the container. As the tests (should) now run in the container, this should not be needed.
The tests also seem to have added complexity due to the recovery tests. As the recovery tests need to be able to kill the container, it mandates manual container lifecycle management for *all* tests. We may want to pull out the recovery tests into a separate module.
We also may want to pull out the DisabledContextPropagationTest into a separate module as they use a modified AS configuration.
We should also take a general look at how the tests are structured and using Arq.
--
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
11 years, 7 months
[JBoss JIRA] (JBTM-1506) Move the XTS DisabledContextPropagationTests into separate module
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1506:
-----------------------------------
Summary: Move the XTS DisabledContextPropagationTests into separate module
Key: JBTM-1506
URL: https://issues.jboss.org/browse/JBTM-1506
Project: JBoss Transaction Manager
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Testing, XTS
Reporter: Paul Robinson
Assignee: Gytis Trikleris
Fix For: 5.0.0.M3
This should make the code for selecting which AS config to use, less complex.
As these tests share a lot of code with the EnabledContextPropagationTests, we could make the new module depend on the 'unit' module.
--
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
11 years, 7 months
[JBoss JIRA] (JBTM-1398) Review subsystem usage across Narayana
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1398?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1398:
--------------------------------
Comment: was deleted
(was: Hi [~paul.robinson] please can you mark this as "stop progress" to move this back to open, unless you are working on it, in which case you need to assign it back to yourself, thanks)
> Review subsystem usage across Narayana
> --------------------------------------
>
> Key: JBTM-1398
> URL: https://issues.jboss.org/browse/JBTM-1398
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Original Estimate: 2 days
> Time Spent: 1 day, 7 hours
> Remaining Estimate: 2 days, 6 hours
>
> h2. Components and their subsystem requirements:
> h5. Transactions
> * To Investigate
>
> h5. XTS
> * Bootstrap coordinator
> * Setup WS endpoints for coordinator
> * Setup WS endpoints for the participants
> * Respond to configuration from standalone-xts.xml
> h5. REST-TX
> * Boostrap the coordinator
> * Setup a REST endpoint for the coordinator
> * Setup a REST endpoint for the participants
> h5. Blacktie
> * Register MDB
> * Register MBean
> h5. STM
> * To Investigate
> h5. TXF
> * Modify the WS handler chain on application deployment
> * Registers a CDI extension
> h2. Notable Dependencies
> h5. TXF
> * Weld -> EJB3 -> Transactions (Could check that each link is valid. Check if subsys or regular dep)
> * JBossWS. Might be able to remove by putting the WS specific stuff into the XTS subsystem.
> h2. Subsystem Breakdown
> Providing we can have 'soft' dependencies it would seem favourable to have all the core features in the transactions subsystem and the optional 'transports' in additional subsystems.
> h5. Transactions
> * All current stuff
> * STM
> * TXF (Unlikely to work due to dependency on Weld for loading a portable extension)
> h5. XTS
> * All Current Stuff
> h5. RTS (new)
> h5. Blacktie (new)
--
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
11 years, 7 months
[JBoss JIRA] (JBTM-1398) Review subsystem usage across Narayana
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1398?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1398:
--------------------------------
Assignee: (was: Tom Jenkinson)
> Review subsystem usage across Narayana
> --------------------------------------
>
> Key: JBTM-1398
> URL: https://issues.jboss.org/browse/JBTM-1398
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Original Estimate: 2 days
> Time Spent: 1 day, 7 hours
> Remaining Estimate: 2 days, 6 hours
>
> h2. Components and their subsystem requirements:
> h5. Transactions
> * To Investigate
>
> h5. XTS
> * Bootstrap coordinator
> * Setup WS endpoints for coordinator
> * Setup WS endpoints for the participants
> * Respond to configuration from standalone-xts.xml
> h5. REST-TX
> * Boostrap the coordinator
> * Setup a REST endpoint for the coordinator
> * Setup a REST endpoint for the participants
> h5. Blacktie
> * Register MDB
> * Register MBean
> h5. STM
> * To Investigate
> h5. TXF
> * Modify the WS handler chain on application deployment
> * Registers a CDI extension
> h2. Notable Dependencies
> h5. TXF
> * Weld -> EJB3 -> Transactions (Could check that each link is valid. Check if subsys or regular dep)
> * JBossWS. Might be able to remove by putting the WS specific stuff into the XTS subsystem.
> h2. Subsystem Breakdown
> Providing we can have 'soft' dependencies it would seem favourable to have all the core features in the transactions subsystem and the optional 'transports' in additional subsystems.
> h5. Transactions
> * All current stuff
> * STM
> * TXF (Unlikely to work due to dependency on Weld for loading a portable extension)
> h5. XTS
> * All Current Stuff
> h5. RTS (new)
> h5. Blacktie (new)
--
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
11 years, 7 months
[JBoss JIRA] (JBTM-1398) Review subsystem usage across Narayana
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1398?page=com.atlassian.jira.plugin.... ]
Work on JBTM-1398 stopped by Tom Jenkinson.
> Review subsystem usage across Narayana
> --------------------------------------
>
> Key: JBTM-1398
> URL: https://issues.jboss.org/browse/JBTM-1398
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Reporter: Paul Robinson
> Assignee: Tom Jenkinson
> Original Estimate: 2 days
> Time Spent: 1 day, 7 hours
> Remaining Estimate: 2 days, 6 hours
>
> h2. Components and their subsystem requirements:
> h5. Transactions
> * To Investigate
>
> h5. XTS
> * Bootstrap coordinator
> * Setup WS endpoints for coordinator
> * Setup WS endpoints for the participants
> * Respond to configuration from standalone-xts.xml
> h5. REST-TX
> * Boostrap the coordinator
> * Setup a REST endpoint for the coordinator
> * Setup a REST endpoint for the participants
> h5. Blacktie
> * Register MDB
> * Register MBean
> h5. STM
> * To Investigate
> h5. TXF
> * Modify the WS handler chain on application deployment
> * Registers a CDI extension
> h2. Notable Dependencies
> h5. TXF
> * Weld -> EJB3 -> Transactions (Could check that each link is valid. Check if subsys or regular dep)
> * JBossWS. Might be able to remove by putting the WS specific stuff into the XTS subsystem.
> h2. Subsystem Breakdown
> Providing we can have 'soft' dependencies it would seem favourable to have all the core features in the transactions subsystem and the optional 'transports' in additional subsystems.
> h5. Transactions
> * All current stuff
> * STM
> * TXF (Unlikely to work due to dependency on Weld for loading a portable extension)
> h5. XTS
> * All Current Stuff
> h5. RTS (new)
> h5. Blacktie (new)
--
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
11 years, 7 months