[
https://issues.apache.org/jira/browse/AMBARI-26636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Himanshu Maurya updated AMBARI-26636:
-------------------------------------
Description:
h2. Summary
Follow-up to AMBARI-26635. Consolidates the remaining duplicated polling in
{{ServiceContext}} (dashboard/services/hosts) into a single centralized fetch,
and fixes several bugs where stale UI state or duplicated polling caused
incorrect behavior or stuck backend requests.
h2. Performance improvements
* {{CachedServiceApi}} ran its own self-contained 30-second cache and
independent polling loop, separate from {{{}ServiceContext{}}}'s own polling.
Removed the redundant cache/loop; the API now always fetches live and notifies
subscribers directly, eliminating a class of stale-cache bugs.
* {{ServiceContext}} was running *three overlapping 5-second polling loops*
against the same {{{}/services{}}}/{{{}/components{}}} endpoints (one inside
{{{}CachedServiceApi{}}}, one hand-rolled timeout loop for service
states/alerts, and one via {{usePolling}} for maintenance/stale-config data).
Consolidated into a single poll that drives all derived state, cutting
duplicate backend load roughly 3x on the dashboard and hosts pages.
* Added WebSocket-driven instant state merges for {{/events/hostcomponents}}
and {{/events/services}} so component/service state updates apply immediately
instead of waiting for the next 5-second poll.
* {{{}HostsList{}}}, the Hosts detail page, and {{RestartWarning}} each
independently re-fetched the same {{/components}} endpoint on their own timers;
they now reuse the centralized polled data from {{{}ServiceContext{}}},
removing 3 more duplicate pollers.
* Several per-service config-updater hooks (HDFS, HBase, Pinot, Ranger,
Spark3, Trino, YARN) re-rendered and cleared their component data even when a
poll cycle returned an empty component list; they now skip the update in that
case, preventing a UI flicker/reset on every empty response.
* Added a session-level cache for the Quicklinks stack-metadata endpoint,
which was being re-fetched on every service switch even though the underlying
config rarely changes.
h2. Bug fixes
* Hosts list page: the host status tooltip listed the wrong "down" components
because it read a field ({{{}HostRoles.state{}}}) that doesn't exist on the
mapped host-component shape; corrected to read {{{}workStatus{}}}.
* Ambari Views ({{{}/views/...{}}} pages) had an extra 80px bottom padding
inherited from the general dashboard layout, causing an unnecessary gap/scroll
area under the view iframe; padding is now suppressed specifically on Views
routes.
* The "Test DB Connection" action could route through the cluster-less action
endpoint ({{{}POST /requests{}}}) when a new service was being added to an
already-installed cluster (not yet "installed" itself). That produced a request
with {{clusterID=-1}} that the backend {{ActionScheduler}} could never resolve,
leaving it stuck in {{PENDING}} forever and blocking all subsequent background
requests. The routing decision now keys off cluster existence rather than
service-install state, and an empty resolved host now fails the check
immediately instead of posting a request that the backend would reject.
h2. Impact
Further reduces redundant polling load on the Ambari server from the Modern UI
(dashboard, hosts, and service pages) beyond AMBARI-26635, and fixes a
request-starvation bug that could stall all background operations until server
restart.
was:
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.
> Ambari Web React: Consolidate ServiceContext polling loops and fix stale UI
> state, stuck test-connection requests
> -----------------------------------------------------------------------------------------------------------------
>
> Key: AMBARI-26636
> URL: https://issues.apache.org/jira/browse/AMBARI-26636
> Project: Ambari
> Issue Type: Story
> Reporter: Himanshu Maurya
> Assignee: Himanshu Maurya
> Priority: Major
> Fix For: 3.1.0
>
>
> h2. Summary
> Follow-up to AMBARI-26635. Consolidates the remaining duplicated polling in
> {{ServiceContext}} (dashboard/services/hosts) into a single centralized
> fetch, and fixes several bugs where stale UI state or duplicated polling
> caused incorrect behavior or stuck backend requests.
> h2. Performance improvements
> * {{CachedServiceApi}} ran its own self-contained 30-second cache and
> independent polling loop, separate from {{{}ServiceContext{}}}'s own polling.
> Removed the redundant cache/loop; the API now always fetches live and
> notifies subscribers directly, eliminating a class of stale-cache bugs.
> * {{ServiceContext}} was running *three overlapping 5-second polling loops*
> against the same {{{}/services{}}}/{{{}/components{}}} endpoints (one inside
> {{{}CachedServiceApi{}}}, one hand-rolled timeout loop for service
> states/alerts, and one via {{usePolling}} for maintenance/stale-config data).
> Consolidated into a single poll that drives all derived state, cutting
> duplicate backend load roughly 3x on the dashboard and hosts pages.
> * Added WebSocket-driven instant state merges for {{/events/hostcomponents}}
> and {{/events/services}} so component/service state updates apply immediately
> instead of waiting for the next 5-second poll.
> * {{{}HostsList{}}}, the Hosts detail page, and {{RestartWarning}} each
> independently re-fetched the same {{/components}} endpoint on their own
> timers; they now reuse the centralized polled data from
> {{{}ServiceContext{}}}, removing 3 more duplicate pollers.
> * Several per-service config-updater hooks (HDFS, HBase, Pinot, Ranger,
> Spark3, Trino, YARN) re-rendered and cleared their component data even when a
> poll cycle returned an empty component list; they now skip the update in that
> case, preventing a UI flicker/reset on every empty response.
> * Added a session-level cache for the Quicklinks stack-metadata endpoint,
> which was being re-fetched on every service switch even though the underlying
> config rarely changes.
> h2. Bug fixes
> * Hosts list page: the host status tooltip listed the wrong "down"
> components because it read a field ({{{}HostRoles.state{}}}) that doesn't
> exist on the mapped host-component shape; corrected to read
> {{{}workStatus{}}}.
> * Ambari Views ({{{}/views/...{}}} pages) had an extra 80px bottom padding
> inherited from the general dashboard layout, causing an unnecessary
> gap/scroll area under the view iframe; padding is now suppressed specifically
> on Views routes.
> * The "Test DB Connection" action could route through the cluster-less
> action endpoint ({{{}POST /requests{}}}) when a new service was being added
> to an already-installed cluster (not yet "installed" itself). That produced a
> request with {{clusterID=-1}} that the backend {{ActionScheduler}} could
> never resolve, leaving it stuck in {{PENDING}} forever and blocking all
> subsequent background requests. The routing decision now keys off cluster
> existence rather than service-install state, and an empty resolved host now
> fails the check immediately instead of posting a request that the backend
> would reject.
> h2. Impact
> Further reduces redundant polling load on the Ambari server from the Modern
> UI (dashboard, hosts, and service pages) beyond AMBARI-26635, and fixes a
> request-starvation bug that could stall all background operations until
> server restart.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
