Bug 966296 - Server startup is delayed if recovery starts before all TX resource plugins register
Server startup is delayed if recovery starts before all TX resource plugins r...
Status: NEW
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: EAP (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Default User
Depends On:
  Show dependency treegraph
Reported: 2013-05-22 20:18 EDT by James Livingston
Modified: 2016-02-21 19:57 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker JBTM-1700 Major Closed RecoveryHelpers may deregister from Recovery Manager during a scan interval 2014-04-10 08:31:09 EDT
Red Hat Knowledge Base (Solution) 376403 None None None Never

  None (edit)
Description James Livingston 2013-05-22 20:18:34 EDT
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)
Comment 1 JBoss JIRA Server 2013-09-25 12:15:26 EDT
Tom Jenkinson <tom.jenkinson@redhat.com> made a comment on jira JBTM-1700

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
Comment 3 JBoss JIRA Server 2013-10-01 12:07:55 EDT
Michael Musgrove <mmusgrov@redhat.com> updated the status of jira JBTM-1700 to Closed
Comment 4 JBoss JIRA Server 2013-11-20 09:38:26 EST
Tom Jenkinson <tom.jenkinson@redhat.com> updated the status of jira JBTM-1700 to Reopened
Comment 5 JBoss JIRA Server 2013-11-20 09:39:22 EST
Tom Jenkinson <tom.jenkinson@redhat.com> updated the status of jira JBTM-1700 to Closed

Note You need to log in before you can comment on or make changes to this bug.