> On April 5, 2017, 5:16 p.m., Alejandro Fernandez wrote: > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeItemResourceProvider.java > > Lines 264 (patched) > > <https://reviews.apache.org/r/58218/diff/1/?file=1685525#file1685525line271> > > > > Let's remove dead code
Ugh - I did remove it, but I didn't stage the change before creating the patch. Thanks! - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/58218/#review171167 ----------------------------------------------------------- On April 5, 2017, 4:40 p.m., Jonathan Hurley wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/58218/ > ----------------------------------------------------------- > > (Updated April 5, 2017, 4:40 p.m.) > > > Review request for Ambari, Alejandro Fernandez, Nate Cole, Robert Levas, and > Sid Wagle. > > > Bugs: AMBARI-20685 > https://issues.apache.org/jira/browse/AMBARI-20685 > > > Repository: ambari > > > Description > ------- > > 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, > 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} > > > Diffs > ----- > > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/StageResourceProvider.java > 8759844 > > ambari-server/src/main/java/org/apache/ambari/server/controller/internal/UpgradeItemResourceProvider.java > bf0fa33 > > ambari-server/src/main/java/org/apache/ambari/server/orm/entities/StageEntity.java > 49c1594 > > ambari-server/src/main/java/org/apache/ambari/server/orm/entities/StageEntityPK.java > 34d175c > > ambari-server/src/main/java/org/apache/ambari/server/state/UpgradeHelper.java > eee913a > > > Diff: https://reviews.apache.org/r/58218/diff/1/ > > > Testing > ------- > > PENDING > > > Thanks, > > Jonathan Hurley > >