You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Jonathan Hurley (JIRA)" <ji...@apache.org> on 2017/04/24 14:49:04 UTC
[jira] [Updated] (AMBARI-20833) Calculation of Effective Cluster
Version During a Large Upgrade is Inefficient
[ https://issues.apache.org/jira/browse/AMBARI-20833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Hurley updated AMBARI-20833:
-------------------------------------
Summary: Calculation of Effective Cluster Version During a Large Upgrade is Inefficient (was: Getting Upgrades In Progress Is Too Heavy And Causes Upgrade Requests To Timeout)
> Calculation of Effective Cluster Version During a Large Upgrade is Inefficient
> ------------------------------------------------------------------------------
>
> Key: AMBARI-20833
> URL: https://issues.apache.org/jira/browse/AMBARI-20833
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: 2.4.0
> Reporter: Jonathan Hurley
> Assignee: Jonathan Hurley
> Priority: Critical
> Fix For: 2.5.1
>
>
> 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:
> {code}
> 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)
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)