[JBoss JIRA] (JBTM-1700) Server startup is delayed if recovery starts before all resource plugins register
by James Livingston (JIRA)
[ https://issues.jboss.org/browse/JBTM-1700?page=com.atlassian.jira.plugin.... ]
James Livingston updated JBTM-1700:
-----------------------------------
Summary: Server startup is delayed if recovery starts before all resource plugins register (was: Server startup is delayed is recovery starts before all resource plugins register)
> Server startup is delayed if recovery starts before all resource plugins register
> ---------------------------------------------------------------------------------
>
> Key: JBTM-1700
> URL: https://issues.jboss.org/browse/JBTM-1700
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: James Livingston
> Assignee: Tom Jenkinson
>
> If the startup of JBoss is sufficiently slow, it is possible for a recovery run to already be in progress when a resource plugin is added. When this occurs, the startup will block until the recovery run has finished.
> It would be much better if starting a recovery run did not block AS startup.
> An example of this occurring on EAP 5 is:
> "main" prio=10 tid=0x00002aac680cc000 nid=0x5e67 waiting for monitor entry [0x00000000412cb000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.addXAResourceRecoveryHelper(XARecoveryModule.java:85)
> - waiting to lock <0x00002aab3e8b9d68> (a java.util.LinkedList)
> at com.arjuna.ats.jbossatx.jta.TransactionManagerService.addXAResourceRecovery(TransactionManagerService.java:695)
> at org.jboss.resource.connectionmanager.ManagedConnectionFactoryDeployment.startService(ManagedConnectionFactoryDeployment.java:500)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:376)
> at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:322)
> at org.jboss.system.ServiceDynamicMBeanSupport.invoke(ServiceDynamicMBeanSupport.java:124)
> at org.jboss.mx.server.RawDynamicInvoker.invoke(RawDynamicInvoker.java:164)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
> at org.jboss.system.server.jmx.LazyMBeanServer.invoke(LazyMBeanServer.java:283)
> at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:189)
> at $Proxy43.start(Unknown Source)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
> at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
> ...
> "Thread-21" prio=10 tid=0x00002aacdd1f7000 nid=0x5ee3 runnable [0x000000004416a000]
> java.lang.Thread.State: RUNNABLE
> ...
> at org.jboss.resource.adapter.jdbc.xa.XAManagedConnection.recover(XAManagedConnection.java:294)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecovery(XARecoveryModule.java:773)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:712)
> - locked <0x00002aab3e8b9d68> (a java.util.LinkedList)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:201)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:799)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:412)
--
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
10 years, 12 months
[JBoss JIRA] (JBTM-1472) Initial version of Compensations API
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1472?focusedWorklogId=12429202&page=... ]
Paul Robinson logged work on JBTM-1472:
---------------------------------------
Author: Paul Robinson
Created on: 22/May/13 3:13 PM
Start Date: 22/May/13 3:13 PM
Worklog Time Spent: 1 day
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 3 days)
Time Spent: 1 week, 1 day, 6 hours (was: 1 week, 6 hours)
Worklog Id: (was: 12429202)
> Initial version of Compensations API
> ------------------------------------
>
> Key: JBTM-1472
> URL: https://issues.jboss.org/browse/JBTM-1472
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transaction Core, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Original Estimate: 2 weeks
> Time Spent: 1 week, 1 day, 6 hours
> Remaining Estimate: 0 minutes
>
> We essentially provide a JTA-like implementation for using compensations. We would support distribution over Web services and REST via WS-BA and REST-JDI. This is similar in how we do distributed ACID transactions today; the application is developed against the JTA, but through configuration we enable distributed transactions over a particular transport (remoting, IIOP, WS).
> It would be good to have some subset of functionality that worked on a raw VM (i.e. no appserver). This would hopefully broaden the market.
> This first piece of work is to do some initial research and support an API with potentially a subset of features of the final API.
> Tasks:
> # Investigate existing WS-BA APIs
> ## Try code examples if possible
> # Produce an initial list of features that should be covered by the API
> # Create a simple implementation backed by WS-BA.
> Implementation work, to complete this issue:
> # Manage lifecycle of transaction via the @Compensatable annotation
> # Allow Compensation and Completion handlers to be registered via annotations
> # Mechanism for allowing application to mark the transaction as CompensateOnly
> # Merge into Narayana code base
> # OOTB support in WildFly
--
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
10 years, 12 months
[JBoss JIRA] (JBTM-1472) Initial version of Compensations API
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1472?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1472:
--------------------------------
Description:
We essentially provide a JTA-like implementation for using compensations. We would support distribution over Web services and REST via WS-BA and REST-JDI. This is similar in how we do distributed ACID transactions today; the application is developed against the JTA, but through configuration we enable distributed transactions over a particular transport (remoting, IIOP, WS).
It would be good to have some subset of functionality that worked on a raw VM (i.e. no appserver). This would hopefully broaden the market.
This first piece of work is to do some initial research and support an API with potentially a subset of features of the final API.
Tasks:
# Investigate existing WS-BA APIs
## Try code examples if possible
# Produce an initial list of features that should be covered by the API
# Create a simple implementation backed by WS-BA.
Implementation work, to complete this issue:
# Manage lifecycle of transaction via the @Compensatable annotation
# Allow Compensation and Completion handlers to be registered via annotations
# Mechanism for allowing application to mark the transaction as CompensateOnly
# Merge into Narayana code base
# OOTB support in WildFly
was:
We essentially provide a JTA-like implementation for using compensations. We would support distribution over Web services and REST via WS-BA and REST-JDI. This is similar in how we do distributed ACID transactions today; the application is developed against the JTA, but through configuration we enable distributed transactions over a particular transport (remoting, IIOP, WS).
It would be good to have some subset of functionality that worked on a raw VM (i.e. no appserver). This would hopefully broaden the market.
This first piece of work is to do some initial research and support an API with potentially a subset of features of the final API.
Tasks:
# Investigate existing WS-BA APIs
## Try code examples if possible
# Produce an initial list of features that should be covered by the API
# Create a simple implementation backed by WS-BA.
Implementation work, to complete this issue:
# Manage lifecycle of transaction via the @Compensatable annotation
# Allow Compensation and Completion handlers to be registered via annotations
# Mechanism for allowing application to mark the transaction as CompensateOnly
# Document the API
# Merge into Narayana code base
# OOTB support in WildFly
> Initial version of Compensations API
> ------------------------------------
>
> Key: JBTM-1472
> URL: https://issues.jboss.org/browse/JBTM-1472
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transaction Core, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Original Estimate: 2 weeks
> Time Spent: 1 week, 6 hours
> Remaining Estimate: 3 days
>
> We essentially provide a JTA-like implementation for using compensations. We would support distribution over Web services and REST via WS-BA and REST-JDI. This is similar in how we do distributed ACID transactions today; the application is developed against the JTA, but through configuration we enable distributed transactions over a particular transport (remoting, IIOP, WS).
> It would be good to have some subset of functionality that worked on a raw VM (i.e. no appserver). This would hopefully broaden the market.
> This first piece of work is to do some initial research and support an API with potentially a subset of features of the final API.
> Tasks:
> # Investigate existing WS-BA APIs
> ## Try code examples if possible
> # Produce an initial list of features that should be covered by the API
> # Create a simple implementation backed by WS-BA.
> Implementation work, to complete this issue:
> # Manage lifecycle of transaction via the @Compensatable annotation
> # Allow Compensation and Completion handlers to be registered via annotations
> # Mechanism for allowing application to mark the transaction as CompensateOnly
> # Merge into Narayana code base
> # OOTB support in WildFly
--
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
10 years, 12 months
[JBoss JIRA] (JBTM-1472) Initial version of Compensations API
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1472?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1472:
--------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/jbosstm/narayana/pull/301
> Initial version of Compensations API
> ------------------------------------
>
> Key: JBTM-1472
> URL: https://issues.jboss.org/browse/JBTM-1472
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transaction Core, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Priority: Critical
> Fix For: 5.0.0.M3
>
> Original Estimate: 2 weeks
> Time Spent: 1 week, 6 hours
> Remaining Estimate: 3 days
>
> We essentially provide a JTA-like implementation for using compensations. We would support distribution over Web services and REST via WS-BA and REST-JDI. This is similar in how we do distributed ACID transactions today; the application is developed against the JTA, but through configuration we enable distributed transactions over a particular transport (remoting, IIOP, WS).
> It would be good to have some subset of functionality that worked on a raw VM (i.e. no appserver). This would hopefully broaden the market.
> This first piece of work is to do some initial research and support an API with potentially a subset of features of the final API.
> Tasks:
> # Investigate existing WS-BA APIs
> ## Try code examples if possible
> # Produce an initial list of features that should be covered by the API
> # Create a simple implementation backed by WS-BA.
> Implementation work, to complete this issue:
> # Manage lifecycle of transaction via the @Compensatable annotation
> # Allow Compensation and Completion handlers to be registered via annotations
> # Mechanism for allowing application to mark the transaction as CompensateOnly
> # Document the API
> # Merge into Narayana code base
> # OOTB support in WildFly
--
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
10 years, 12 months
[JBoss JIRA] (JBTM-1677) Enable Compensations interceptors by default
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1677?focusedWorklogId=12429201&page=... ]
Paul Robinson logged work on JBTM-1677:
---------------------------------------
Author: Paul Robinson
Created on: 22/May/13 8:24 AM
Start Date: 22/May/13 8:24 AM
Worklog Time Spent: 2 hours
Issue Time Tracking
-------------------
Remaining Estimate: 0 minutes (was: 4 hours)
Time Spent: 2 hours
Worklog Id: (was: 12429201)
> Enable Compensations interceptors by default
> --------------------------------------------
>
> Key: JBTM-1677
> URL: https://issues.jboss.org/browse/JBTM-1677
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: TXFramework, XTS
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M3
>
> Original Estimate: 4 hours
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> Currently they need to be registered in the beans.xml of the 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
10 years, 12 months
[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1702:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/300/files
Thanks for the report, I have put back a PR for this. I will merge it once CI is ran over it.
> one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success
> -------------------------------------------------------------------------------------------------
>
> Key: JBTM-1702
> URL: https://issues.jboss.org/browse/JBTM-1702
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 5.0.0.M2
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
>
> We provide our own XAResource implementation for our database product,
> in our unit testsuite we do also test common error conditions.
> The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback.
> The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure.
> The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored.
> This error occurs if and only if the one-phase optimization is used, i.e. if
> exactly one XAResource instance is enlisted with the TransactionManager.
> If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully.
> The broken logic is contained in here (also see a complete stack trace below):
> com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes.
> FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure.
> This is the complete stacktrace of our exception (logged immediately prior before it was thrown):
> About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost].
> at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553)
> at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54)
> at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92)
--
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
10 years, 12 months