[JBoss JIRA] (JBTM-1944) Merge blacktie and narayana scripts
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-1944:
-----------------------------------
Summary: Merge blacktie and narayana scripts
Key: JBTM-1944
URL: https://issues.jboss.org/browse/JBTM-1944
Project: JBoss Transaction Manager
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Build System
Reporter: Tom Jenkinson
Assignee: Tom Jenkinson
Priority: Minor
Fix For: 5.0.0.M5
There are still two sets of scripts for building narayana and blacktie
build.*
blacktie/build.*
scripts/hudson/narayana.*
blacktie/scripts/hudson/blacktie-*
Merge them to simplify
--
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, 2 months
[JBoss JIRA] (JBTM-1700) Server startup is delayed if recovery starts before all resource plugins register
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1700?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1700:
--------------------------------
Git Pull Request: https://github.com/jbosstm/narayana/pull/460, https://github.com/jbosstm/narayana/pull/461 (was: https://github.com/jbosstm/narayana/pull/460)
> 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)
> 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, 2 months
[JBoss JIRA] (JBTM-1700) Server startup is delayed if recovery starts before all resource plugins register
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1700?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1700:
--------------------------------
Fix Version/s: 4.17.11
> 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)
> 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, 2 months
[JBoss JIRA] (JBTM-1700) Server startup is delayed if recovery starts before all resource plugins register
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1700?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1700:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/460
In reality this change had already been made in versions > 4.17.x, however there was an issue in that recovery helpers were no longer stopped from delisting from the recovery manager between scan phases and so I have corrected that
> 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)
> Components: JTA, Recovery
> Reporter: James Livingston
> Assignee: Tom Jenkinson
> Fix For: 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, 2 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]
So, like I mentioned above. I have raised a PR on JBTM with a change to allow the value to be configurable, however exposing this to via standalone.xml config would require a change to the app server.
That said, with the PR merged, the config can still be enabled in an unsupported manner via a system property:
com.arjuna.ats.jta.JTAEnvironmentBean.orphanSafetyInterval (default is 10000)
> 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, 2 months
[JBoss JIRA] (JBTM-1943) Allow the safety interval for RecoveryXids to be configurable
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1943?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1943:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/459
> 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, 2 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 updated JBTM-1943:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1009981
> 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, 2 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]
I created an enhancement request over on Jira for you for the JBTM part. There would need to be a WFLY issue to expose the new config via the AS for it to be formally accepted as supportable (and QE would need to test it)
> 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, 2 months
[JBoss JIRA] (JBTM-1943) Allow the safety interval for RecoveryXids to be configurable
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1943?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1943:
--------------------------------
Description:
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.
was: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.
> 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, 2 months
[JBoss JIRA] (JBTM-1943) Allow the safety interval for RecoveryXids to be configurable
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-1943:
-----------------------------------
Summary: 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.
--
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, 2 months