Mailing-List: contact issues-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Mon, 24 Apr 2017 19:29:04 +0000 (UTC)
From: "Hudson (JIRA)" <jira@apache.org>
To: issues@ambari.apache.org
Message-ID: <JIRA.13066364.1493045192000.37041.1493062144217@Atlassian.JIRA>
In-Reply-To: <JIRA.13066364.1493045192000@Atlassian.JIRA>
References: <JIRA.13066364.1493045192000@Atlassian.JIRA> <JIRA.13066364.1493045192153@jira-lw-us.apache.org>
Subject: [jira] [Commented] (AMBARI-20833) Calculation of Effective Cluster
 Version During a Large Upgrade is Inefficient
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 24 Apr 2017 19:29:09 -0000


    [ https://issues.apache.org/jira/browse/AMBARI-20833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15981739#comment-15981739 ] 

Hudson commented on AMBARI-20833:
---------------------------------

SUCCESS: Integrated in Jenkins build Ambari-trunk-Commit #7346 (See [https://builds.apache.org/job/Ambari-trunk-Commit/7346/])
AMBARI-20833 - Calculation of Effective Cluster Version During a Large (jhurley: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=2958fbefb069be22a2e6140a102ec87e6b7e1ad5])
* (edit) ambari-server/src/main/java/org/apache/ambari/server/state/cluster/ClusterImpl.java
* (edit) ambari-server/src/test/java/org/apache/ambari/server/state/cluster/ClusterEffectiveVersionTest.java
* (edit) ambari-server/src/main/java/org/apache/ambari/server/serveraction/upgrades/UpdateDesiredStackAction.java
* (edit) ambari-server/src/main/java/org/apache/ambari/server/state/Cluster.java


> 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
>
>         Attachments: AMBARI-20833.patch
>
>
> 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)