ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hurley (JIRA)" <>
Subject [jira] [Updated] (AMBARI-20833) Calculation of Effective Cluster Version During a Large Upgrade is Inefficient
Date Mon, 24 Apr 2017 14:49:04 GMT


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:
>             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(
> 	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$MethodProxy.invokeSuper(
> 	at$InterceptedMethodInvocation.proceed(
> 	at org.apache.ambari.server.orm.AmbariLocalSessionInterceptor.invoke(
> 	at$InterceptedMethodInvocation.proceed(
> 	at
> 	at org.apache.ambari.server.orm.dao.HostRoleCommandDAO$$EnhancerByGuice$$51ca179d.findByRequestIdAndStatuses(<generated>)
> 	at org.apache.ambari.server.state.cluster.ClusterImpl.getUpgradeInProgress(
> 	at org.apache.ambari.server.state.cluster.ClusterImpl.getEffectiveClusterVersion(
> 	at org.apache.ambari.server.controller.AmbariCustomCommandExecutionHelper.addCustomCommandAction(
> 	at org.apache.ambari.server.controller.AmbariCustomCommandExecutionHelper.addExecutionCommandsToStage(
> 	at org.apache.ambari.server.controller.internal.UpgradeResourceProvider.makeCommandStage(
> 	at org.apache.ambari.server.controller.internal.UpgradeResourceProvider.createStage(
> 	at org.apache.ambari.server.controller.internal.UpgradeResourceProvider.createUpgrade(
> {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

View raw message