Abhishek Pal created HDDS-9124:
----------------------------------
Summary: [Recon] Network requests not canceled when context changes
Key: HDDS-9124
URL: https://issues.apache.org/jira/browse/HDDS-9124
Project: Apache Ozone
Issue Type: Improvement
Components: Ozone Recon
Reporter: Abhishek Pal
Assignee: Abhishek Pal
Attachments: HDDS-9124.mp4
With the current code for Recon UI, we are not handling scenarios where network
requests should be cancelled when user is shifting pages/context.
This causes unnecessary requests to be made.
For example if the user opens the Recon UI and selects a view, then the user
changes that view immediately, the request for the previous view will still go
through, along with the new request for the changed view.
This is more noticeable in a slow network, where requests might be stuck in a
pending state, and during that time if we switch the view the previous request
will still be sent, along with the new request.
The scenario is attached in the video recording, where a slow 3G network is
being emulated.
If we are clicking on DiskUsage view it sends a request to:
{panel} .../du?path=/&files=true {panel}
Now if we click on the Containers view the second request is being sent for:
{panel}.../unhealthy {panel}
At this point we will notice both the requests to be in a pending state. And
later both the requests are resolved.
Ideally we should be cancelling the DiskUsage request the moment we shift to
the container view.
----
Note: This might not be affecting in an environment where users might be going
through the data in Recon and they are expected to not cancel/change views
immediately. But there might still be scenarios where the users click on the
wrong view and later click on the correct option.
For a small number of requests it is acceptable, but as the codebase grows and
there are several features, mixed along with increased latency in network, this
might become a problem and use up resources to serve requests that are no
longer required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
