[JBoss JIRA] (JBTM-1779) txframework DataManagementTest does not work under emma
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1779?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1779:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/468
> txframework DataManagementTest does not work under emma
> -------------------------------------------------------
>
> Key: JBTM-1779
> URL: https://issues.jboss.org/browse/JBTM-1779
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, TXFramework
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.M5
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> There is a single txf test that does not run correctly under emma. It complains about not being able to find vladium.
> The problem appears to be that this test creates an arq deployment containing its own copy of the TXDataMap rather than trying to use the one that is deployed already in the AS and is therefore in a different classloader so can't see the shaded emma classes from the real module.
> When I modify the test to remove that class and use the txf module directly, the same as all the other tests in the txf module, it can't load the TXDM class from the module. The difference is that the TXDM is injected into test beans that are injected into the tests, rather than directly injected. I think this could be a limitation of Emma.
--
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, 3 months
[JBoss JIRA] (JBTM-1943) Allow the safety interval for RecoveryXids to be configurable
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1943?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-1943:
-----------------------------------------------
tom.jenkinson(a)redhat.com made a comment on [bug 1009981|https://bugzilla.redhat.com/show_bug.cgi?id=1009981]
The component upgrade linked to provides the ability to set the value you need via a system property, it does not expose the value to the CLI
> Allow the safety interval for RecoveryXids to be configurable
> -------------------------------------------------------------
>
> Key: JBTM-1943
> URL: https://issues.jboss.org/browse/JBTM-1943
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA
> Reporter: Tom Jenkinson
> Assignee: Tom Jenkinson
> Fix For: 4.17.11, 5.0.0.M5
>
>
> Currently it is hard coded to 10 seconds. It is possible that under load this could be possible to breach. Allow the setting to be configurable.
> Breaching the threshold does not pose data integrity issues as the scenario where it becomes an issue is when the transaction has completed during a recovery scan. It will result in calling rollback(xid1) on the RM but as that RM is guaranteed to have had commit(xid1) (or rollback) on it already during transaction completion the only impact is an unsightly stack trace.
--
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, 3 months
[JBoss JIRA] (JBTM-1946) Remove quickstarts that use the old Compensations API
by Paul Robinson (JIRA)
Paul Robinson created JBTM-1946:
-----------------------------------
Summary: Remove quickstarts that use the old Compensations API
Key: JBTM-1946
URL: https://issues.jboss.org/browse/JBTM-1946
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Demonstrator, TXFramework
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M5
wsba-to-jta and wsba-simple where replaced with travel-agent and non-transactional_resource (respectively).
--
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, 3 months
[JBoss JIRA] (JBTM-1804) JTS remote tests not run and no code coverage
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1804?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1804:
--------------------------------
Fix Version/s: 5.0.0.Final
(was: 5.0.0.M5)
> JTS remote tests not run and no code coverage
> ---------------------------------------------
>
> Key: JBTM-1804
> URL: https://issues.jboss.org/browse/JBTM-1804
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JTS, Testing
> Affects Versions: 5.0.0.M3
> Reporter: Mark Little
> Assignee: Amos Feng
> Fix For: 5.0.0.Final
>
>
> The tests in .remote. package for JTS are not run by default. We should consider adding a build option so that they are run (will require some mods to the tests since many of them are client/server based - see associated Readme.txt files); don't run them by default since they will add delay to a normal build.
> It would then be beneficial to have them instrumented by emma to get code coverage.
--
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, 3 months
[JBoss JIRA] (JBTM-1700) RecoveryHelpers may deregister from Recovery Manager during a scan interval
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1700?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1700:
--------------------------------
Description:
This was uncovered invesigating:
"Server startup is delayed if recovery starts before all resource plugins register"
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)
was:
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)
> RecoveryHelpers may deregister from Recovery Manager during a scan interval
> ---------------------------------------------------------------------------
>
> Key: JBTM-1700
> URL: https://issues.jboss.org/browse/JBTM-1700
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTA, Recovery
> Reporter: James Livingston
> Assignee: Tom Jenkinson
> Fix For: 4.17.11, 5.0.0.M5
>
>
> This was uncovered invesigating:
> "Server startup is delayed if recovery starts before all resource plugins register"
> 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
11 years, 3 months
[JBoss JIRA] (JBTM-1700) RecoveryHelpers may deregister from Recovery Manager during a scan interval
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1700?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1700:
--------------------------------
Summary: RecoveryHelpers may deregister from Recovery Manager during a scan interval (was: Server startup is delayed if recovery starts before all resource plugins register)
> RecoveryHelpers may deregister from Recovery Manager during a scan interval
> ---------------------------------------------------------------------------
>
> Key: JBTM-1700
> URL: https://issues.jboss.org/browse/JBTM-1700
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JTA, Recovery
> Reporter: James Livingston
> Assignee: Tom Jenkinson
> Fix For: 4.17.11, 5.0.0.M5
>
>
> 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
11 years, 3 months