ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMBARI-20685) Upgrade Progress Dialog Executes Query Which Causes StackOverflow in JPA
Date Thu, 06 Apr 2017 16:23:41 GMT

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

Hudson commented on AMBARI-20685:
---------------------------------

FAILURE: Integrated in Jenkins build Ambari-trunk-Commit #7249 (See [https://builds.apache.org/job/Ambari-trunk-Commit/7249/])
AMBARI-20685 - Upgrade Progress Dialog Executes Query Which Causes (jhurley: [http://git-wip-us.apache.org/repos/asf?p=ambari.git&a=commit&h=92894811ec18ce5eae9aa10071f3bad022d4bcf5])
* (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeItemResourceProvider.java
* (edit) ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StageResourceProvider.java
* (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/entities/StageEntityPK.java
* (edit) ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeHelper.java
* (edit) ambari-server/src/main/java/org/apache/ambari/server/orm/entities/StageEntity.java


> Upgrade Progress Dialog Executes Query Which Causes StackOverflow in JPA
> ------------------------------------------------------------------------
>
>                 Key: AMBARI-20685
>                 URL: https://issues.apache.org/jira/browse/AMBARI-20685
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-server
>    Affects Versions: 2.4.2
>            Reporter: Jonathan Hurley
>            Assignee: Jonathan Hurley
>            Priority: Critical
>             Fix For: 2.5.1
>
>         Attachments: AMBARI-20685.patch
>
>
> Large rolling upgrades (1000 hosts with 10,000 host components) creates a massive request
object object with 10's of 1000's of stages and tasks. The web client executes a {{GET}} command
against the API to retrieve upgrade groups/items. On a large upgrade, this causes the EclipseLink
SQL generation code to run out of stack frame space while recursively building a query. To
work around this, the stack frame size per thread can be increased using {{-Xss}} along with
a value like 32M.
> {code}
> http://localhost:8080/api/v1/clusters/c1/upgrades/12?
> upgrade_groups/UpgradeGroup/status!=PENDING&
> fields=
>   Upgrade/progress_percent,
>   Upgrade/request_context,
>   Upgrade/request_status,
>   Upgrade/direction,
>   Upgrade/downgrade_allowed,
>   upgrade_groups/UpgradeGroup,
>   Upgrade/*,
>   upgrade_groups/upgrade_items/UpgradeItem/status,
>   upgrade_groups/upgrade_items/UpgradeItem/display_status,
>   upgrade_groups/upgrade_items/UpgradeItem/context,
>   upgrade_groups/upgrade_items/UpgradeItem/group_id,
>   upgrade_groups/upgrade_items/UpgradeItem/progress_percent,
>   upgrade_groups/upgrade_items/UpgradeItem/request_id,
>   upgrade_groups/upgrade_items/UpgradeItem/skippable,
>   upgrade_groups/upgrade_items/UpgradeItem/stage_id,
>   upgrade_groups/upgrade_items/UpgradeItem/text&
>   minimal_response=true&_=1489680258782
> {code}
> This call gets turn into a LOT of queries, but some seem to be based on the number of
stages. For example, this one on a very small upgrade produces very poor SQL...
> {code}
> SELECT
>   stage_id,
>   cluster_host_info,
>   cluster_id,
>   command_execution_type,
>   command_params,
>   display_status,
>   host_params,
>   log_info,
>   request_context,
>   request_id,
>   skippable,
>   status,
>   supports_auto_skip_failure
> FROM stage
> WHERE ((request_id = ?)
> AND ((((((((stage_id = ?)
> OR (stage_id = ?))
> OR (stage_id = ?))
> OR (stage_id = ?))
> OR (stage_id = ?))
> OR (stage_id = ?))
> OR (stage_id = ?))
> OR (stage_id = ?)))
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message