You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Hadoop QA (JIRA)" <ji...@apache.org> on 2015/11/19 22:13:11 UTC
[jira] [Commented] (AMBARI-13974) Retreiving Failed Service Checks
Takes Too Long On Large Clusters
[ https://issues.apache.org/jira/browse/AMBARI-13974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15014367#comment-15014367 ]
Hadoop QA commented on AMBARI-13974:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12773320/AMBARI-13974.patch
against trunk revision .
{color:red}-1 patch{color}. Top-level trunk compilation may be broken.
Console output: https://builds.apache.org/job/Ambari-trunk-test-patch/4352//console
This message is automatically generated.
> Retreiving Failed Service Checks Takes Too Long On Large Clusters
> -----------------------------------------------------------------
>
> Key: AMBARI-13974
> URL: https://issues.apache.org/jira/browse/AMBARI-13974
> Project: Ambari
> Issue Type: Bug
> Components: ambari-server
> Affects Versions: 2.0.0
> Reporter: Jonathan Hurley
> Assignee: Jonathan Hurley
> Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13974.patch
>
>
> *STR:*
> * Launch Rolling Upgrade on big cluster (500+ node)
> * Proceed to Finalize step
> *Actual Result:*
> Call:
> {code}
> /api/v1/clusters/c500/upgrades/69/upgrade_groups?upgrade_items/UpgradeItem/status=COMPLETED&upgrade_items/tasks/Tasks/status.in(FAILED,ABORTED,TIMEDOUT)&upgrade_items/tasks/Tasks/command=SERVICE_CHECK&fields=upgrade_items/tasks/Tasks/command_detail,upgrade_items/tasks/Tasks/status&minimal_response=true
> {code}
> This call fails due to timeout. No failed Service Checks shown to user.
> The root of the problem is how the REST API handles subqueries. For every group that matches, it will attempt to retrieve every stage and every task and then produce a slice of results from in-memory comparison.
> This should really go through the JPA layer since it's simple comparisons on DB fields.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)