[JBoss JIRA] (JBTM-1700) Server startup is delayed is 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 commented on JBTM-1700:
----------------------------------------
This occurs because XARecoveryModule.addXAResourceRecoveryHelper() and XARecoveryModule.periodicWorkSecondPass() both need to lock the list. Switching to a CopyOnWriteArrayList or similar would let it add the plugin which would get picked up on the next pass, but that would prevent the recovery pass from blocking shutdown too.
> Server startup is delayed is 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
11 years, 4 months
[JBoss JIRA] (JBTM-1700) Server startup is delayed is recovery starts before all resource plugins register
by James Livingston (JIRA)
James Livingston created JBTM-1700:
--------------------------------------
Summary: Server startup is delayed is 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
11 years, 4 months
[JBoss JIRA] (JBTM-1695) Change the 'common' module to use the normal maven convention for source layout.
by Paul Gier (JIRA)
[ https://issues.jboss.org/browse/JBTM-1695?page=com.atlassian.jira.plugin.... ]
Paul Gier commented on JBTM-1695:
---------------------------------
I created a new PR (https://github.com/jbosstm/narayana/pull/296) because the one from Weinan included some extra merge commits, and didn't account for other modules which depend on the source path.
{quote}
can you clarify if there is an EAP issue with the code
{quote}
It's not a serious issue, it just makes the build a bit easier to read and maintain. There is also sometimes a risk that certain plugins depend on the standard layout instead of reading the configured directory from the pom (although I think this is pretty rare now). Since the newer modules already use the Maven directory standards, it seems like it makes sense to make them all the same. But it's ok to reject this if it causes problems for people who are familiar with the old layout.
{quote}
It also makes the history a lot harder to navigate, if you re-name the directory structure.
{quote}
This shouldn't be as much of an issue now that the project uses git. You just have to use "git log --follow" or have an IDE that supports that option.
> Change the 'common' module to use the normal maven convention for source layout.
> --------------------------------------------------------------------------------
>
> Key: JBTM-1695
> URL: https://issues.jboss.org/browse/JBTM-1695
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 4.17.4
> Reporter: Weinan Li
> Assignee: Weinan Li
>
> The common module doesn't use the normal maven convention for source layout.
--
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, 4 months
[JBoss JIRA] (JBTM-1691) Auto-merge in narayana.sh is not robust enough
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1691?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1691:
-------------------------------------
I think the problem is therefore that we need to somehow make sure the .M2 commit from upstream is included into 5_BRANCH in the right place once the M2 commit is merged?
> Auto-merge in narayana.sh is not robust enough
> ----------------------------------------------
>
> Key: JBTM-1691
> URL: https://issues.jboss.org/browse/JBTM-1691
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Tom Jenkinson
> Fix For: 4.17.5, 5.0.0.M3
>
>
> This can't be auto=merged:
> {code}
> <<<<<<< HEAD
> <version.org.jboss.jbossts.jbossjts>5.0.0.M2</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M2</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M2</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.2.0.Beta1</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M2</version.org.jboss.jbossts.narayana>
> =======
> <version.org.jboss.jbossts.jbossjts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.1.0.Final</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.narayana>
> >>>>>>> Upgrade Narayana to 5.0.0.M3-SNAPSHOT
> {code}
> Our current strategy will take our version which results in the old version of jboss-vfs being used, which in turn causes a build failure in WildFly.
> Maybe we should remove the auto-merge and replace with a manual intervention when a conflict occurs?
--
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, 4 months
[JBoss JIRA] (JBTM-1691) Auto-merge in narayana.sh is not robust enough
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1691?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1691:
-------------------------------------
the issue was that we *didn't* want to change the version number. We changed the lines surrounding it and then upstream changed the jboss-vfs line, which caused the conflict.
> Auto-merge in narayana.sh is not robust enough
> ----------------------------------------------
>
> Key: JBTM-1691
> URL: https://issues.jboss.org/browse/JBTM-1691
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Reporter: Paul Robinson
> Assignee: Tom Jenkinson
> Fix For: 4.17.5, 5.0.0.M3
>
>
> This can't be auto=merged:
> {code}
> <<<<<<< HEAD
> <version.org.jboss.jbossts.jbossjts>5.0.0.M2</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M2</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M2</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.2.0.Beta1</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M2</version.org.jboss.jbossts.narayana>
> =======
> <version.org.jboss.jbossts.jbossjts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts>
> <version.org.jboss.jbossts.jbossjts-integration>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossjts-integration>
> <version.org.jboss.jbossts.jbossxts>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.jbossxts>
> <version.org.jboss.jboss-vfs>3.1.0.Final</version.org.jboss.jboss-vfs>
> <version.org.jboss.jbossts.narayana>5.0.0.M3-SNAPSHOT</version.org.jboss.jbossts.narayana>
> >>>>>>> Upgrade Narayana to 5.0.0.M3-SNAPSHOT
> {code}
> Our current strategy will take our version which results in the old version of jboss-vfs being used, which in turn causes a build failure in WildFly.
> Maybe we should remove the auto-merge and replace with a manual intervention when a conflict occurs?
--
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, 4 months
[JBoss JIRA] (JBTM-1422) Deployment failure because of missing service dependencies
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1422?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1422:
-------------------------------------
Those 3 tests where caused by JBTM-1693.
> Deployment failure because of missing service dependencies
> ----------------------------------------------------------
>
> Key: JBTM-1422
> URL: https://issues.jboss.org/browse/JBTM-1422
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Gytis Trikleris
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 5.0.0.Final
>
>
> See: http://172.17.131.2/job/narayana/141
> {noformat}
> org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase Time elapsed: 16103 sec <<< ERROR!
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: wsba-participant-completion.war
> at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
> at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
> ...
> Caused by: java.lang.Exception: {
> "JBAS014771: Services with missing/unavailable dependencies" => ["jboss.module.service.\"deployment.wsba-participant-completion.war\".main is missing [jboss.module.spec.service.\"deployment.arquillian-service\".main]"],
> "JBAS014879: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => ["jboss.deployment.unit.\"wsba-participant-completion.war\".FIRST_MODULE_USE"],
> "Services that may be the cause:" => [
> "jboss.module.spec.service.\"deployment.arquillian-service\".main",
> "jboss.txn.TransactionSynchronizationRegistry",
> "jboss.txn.UserTransactionRegistry"
> ]
> }
> }
> ...
> {noformat}
> {noformat}
> org.jboss.as.test.xts.simple.wsat.client.WSATTestCase Time elapsed: 1846 sec <<< ERROR!
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: wsat.war
> at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
> ...
> Caused by: java.lang.Exception: {
> "JBAS014771: Services with missing/unavailable dependencies" => ["jboss.module.service.\"deployment.wsat.war\".main is missing [jboss.module.spec.service.\"deployment.arquillian-service\".main]"],
> "JBAS014879: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => ["jboss.deployment.unit.\"wsat.war\".FIRST_MODULE_USE"],
> "Services that may be the cause:" => [
> "jboss.module.spec.service.\"deployment.arquillian-service\".main",
> "jboss.txn.TransactionSynchronizationRegistry",
> "jboss.txn.UserTransactionRegistry"
> ]
> }
> }
> ...
> {noformat}
--
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, 4 months