[
https://issues.apache.org/jira/browse/AMBARI-26635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Himanshu Maurya updated AMBARI-26635:
-------------------------------------
Description:
Several React UI components independently fetch or poll data that is already
available elsewhere in the app, causing duplicate/redundant network traffic
against the Ambari server:
* Server clock time is fetched separately by the HDFS, HBase, and YARN config
updater hooks on every mount instead of once at app startup.
* service_check_supported is fetched via a dedicated per-service API call in
both RunAllServiceCheck and the service Actions menu, instead of being read
once from the initial stack configuration response.
* The service Actions menu fetches a service's state via its own
getServiceState call instead of reusing the state already being polled
centrally for the sidebar/dashboard.
* useStackVersion fetches and re-transforms the full stack version list on
every component mount instead of loading it once and sharing it.
* Navbar, ServiceSummary, the Alerts list page, and Alert Definition Details
each independently poll or fetch alert groups/definitions/summary on their own
timers (mostly every 30s), multiplying alert-related API calls across the page.
Proposed fix:
* Centralize server clock time, service_check_supported, and stack version
list fetching into the top-level app context (AppContext), loaded once and
shared by all consumers.
* Introduce a shared AlertsContext that loads alert groups/definitions/
summary once, keeps them current via the existing /events/alerts WebSocket
topic, and restricts polling of the unhealthy-alerts list to only the Alerts
page. All alert-consuming components (Navbar, ServiceSummary, Alerts,
AlertDefinitionDetails) read from this shared context instead of fetching
independently.
* Have CentralizedServiceStateApi derive per-service alert counts from the
shared alert data instead of issuing its own separate /alerts API call.
This reduces the number of duplicate REST calls issued by the Modern (React)
Ambari UI, particularly on pages with many services/alerts, without changing
any user-visible behavior.
was:
The {{usePolling}} hook triggers API calls at fixed intervals without checking
if the previous call has completed. This creates a cascading problem where
multiple identical API requests are in-flight simultaneously.
*Impact on Application:*
# {*}Network Congestion{*}: Multiple identical requests in flight
simultaneously
# {*}Race Conditions{*}: Responses arriving out of order causing state
inconsistencies
# {*}Server Load{*}: Backend processing duplicate requests unnecessarily
# {*}Memory Pressure{*}: Multiple promise chains and response objects in memory
# {*}UI Freezes{*}: Multiple callbacks processing large response data
simultaneously (contributing to 1+ second blocking tasks)
# {*}Wasted Resources{*}: Network bandwidth, CPU cycles, memory for duplicate
data
# {*}Cascading Updates{*}: Multiple state updates from overlapping responses
trigger mass re-renders
*Evidence from Analysis:*
* 3 overlapping polling loops running at 5-second intervals
* No abort mechanism for in-flight requests
* No queue management for pending calls
* API responses can take 3-8 seconds but polling interval is only 5 seconds
* Contributes to 467 long tasks and constant UI updates
> Ambari Web React: Reduce redundant API calls and polling in dashboard,
> alerts, and services pages
> -------------------------------------------------------------------------------------------------
>
> Key: AMBARI-26635
> URL: https://issues.apache.org/jira/browse/AMBARI-26635
> Project: Ambari
> Issue Type: Story
> Reporter: Himanshu Maurya
> Assignee: Himanshu Maurya
> Priority: Major
> Fix For: 3.1.0
>
>
> Several React UI components independently fetch or poll data that is already
> available elsewhere in the app, causing duplicate/redundant network traffic
> against the Ambari server:
> * Server clock time is fetched separately by the HDFS, HBase, and YARN
> config updater hooks on every mount instead of once at app startup.
> * service_check_supported is fetched via a dedicated per-service API call in
> both RunAllServiceCheck and the service Actions menu, instead of being read
> once from the initial stack configuration response.
> * The service Actions menu fetches a service's state via its own
> getServiceState call instead of reusing the state already being polled
> centrally for the sidebar/dashboard.
> * useStackVersion fetches and re-transforms the full stack version list on
> every component mount instead of loading it once and sharing it.
> * Navbar, ServiceSummary, the Alerts list page, and Alert Definition Details
> each independently poll or fetch alert groups/definitions/summary on their
> own timers (mostly every 30s), multiplying alert-related API calls across the
> page.
> Proposed fix:
> * Centralize server clock time, service_check_supported, and stack version
> list fetching into the top-level app context (AppContext), loaded once and
> shared by all consumers.
> * Introduce a shared AlertsContext that loads alert groups/definitions/
> summary once, keeps them current via the existing /events/alerts WebSocket
> topic, and restricts polling of the unhealthy-alerts list to only the Alerts
> page. All alert-consuming components (Navbar, ServiceSummary, Alerts,
> AlertDefinitionDetails) read from this shared context instead of fetching
> independently.
> * Have CentralizedServiceStateApi derive per-service alert counts from the
> shared alert data instead of issuing its own separate /alerts API call.
> This reduces the number of duplicate REST calls issued by the Modern (React)
> Ambari UI, particularly on pages with many services/alerts, without changing
> any user-visible behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
