[AMBARI-20833] Calculation of Effective Cluster Version During a Large Upgrade is Inefficient

• Type: Bug
• Status: Resolved
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 2.4.0
• Fix Version/s: 2.5.1
• Component/s: ambari-server
• Assignee: Jonathan Hurley
• Reporter: Jonathan Hurley
• Created: 24/Apr/17 14:46
• Updated: 24/Apr/17 19:28
• Resolved: 24/Apr/17 18:36

Description

On clusters which are large (1000's of hosts, 10's of 1000's of components), prior upgrades which have been finalized can cause problems when starting future upgrades:

	at org.apache.ambari.server.orm.dao.HostRoleCommandDAO.findByRequestIdAndStatuses(HostRoleCommandDAO.java:321)
	at org.apache.ambari.server.orm.dao.HostRoleCommandDAO$$EnhancerByGuice$$51ca179d.CGLIB$findByRequestIdAndStatuses$2(<generated>)
	at org.apache.ambari.server.orm.dao.HostRoleCommandDAO$$EnhancerByGuice$$51ca179d$$FastClassByGuice$$2f8d96f3.invoke(<generated>)
	at com.google.inject.internal.cglib.proxy.$MethodProxy.invokeSuper(MethodProxy.java:228)
	at com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:72)
	at org.apache.ambari.server.orm.AmbariLocalSessionInterceptor.invoke(AmbariLocalSessionInterceptor.java:53)
	at com.google.inject.internal.InterceptorStackCallback$InterceptedMethodInvocation.proceed(InterceptorStackCallback.java:72)
	at com.google.inject.internal.InterceptorStackCallback.intercept(InterceptorStackCallback.java:52)
	at org.apache.ambari.server.orm.dao.HostRoleCommandDAO$$EnhancerByGuice$$51ca179d.findByRequestIdAndStatuses(<generated>)
	at org.apache.ambari.server.state.cluster.ClusterImpl.getUpgradeInProgress(ClusterImpl.java:1234)
	at org.apache.ambari.server.state.cluster.ClusterImpl.getEffectiveClusterVersion(ClusterImpl.java:1251)
	at org.apache.ambari.server.controller.AmbariCustomCommandExecutionHelper.addCustomCommandAction(AmbariCustomCommandExecutionHelper.java:439)
	at org.apache.ambari.server.controller.AmbariCustomCommandExecutionHelper.addExecutionCommandsToStage(AmbariCustomCommandExecutionHelper.java:1039)
	at org.apache.ambari.server.controller.internal.UpgradeResourceProvider.makeCommandStage(UpgradeResourceProvider.java:1520)
	at org.apache.ambari.server.controller.internal.UpgradeResourceProvider.createStage(UpgradeResourceProvider.java:1311)
	at org.apache.ambari.server.controller.internal.UpgradeResourceProvider.createUpgrade(UpgradeResourceProvider.java:973)

AMBARI-20672 partially fixes this by keeping the UpgradeEntity association in even during suspended upgrades. Therefore, a query against HostRoleCommandDAO isn't needed anymore. However, if an upgrade is in progress, we must still walk the upgrade to determine if the UpdateDesiredStackAction has been called yet. This calculation can be cached and invalidated to prevent the need to traverse a massive upgrade hierarchy.

Issue Links

• links to: Reviewboard