HDDS-14913. Implement Scalable CSV Export for Unhealthy Containers in Recon UI.#10162
Conversation
|
@ArafatKhan2198 as discussed, please design the solution server based for single Recon user. We don't have user based logins in Recon. We should not localize the logic at browser for job progress. All browser windows opened in multiple machines opening the recon page should see the same job and its progress. At a time only job should be allowed to run and remaining 2 should go in queue. |
sumitagrawl
left a comment
There was a problem hiding this comment.
@ArafatKhan2198 Thanks for working, given few comments
devmadhuu
left a comment
There was a problem hiding this comment.
Thanks @ArafatKhan2198 for improving the patch. However few comments, pls check.
Also I am not sure of any cleanup or TTL for completed jobs. How these exported files will be cleaned up, what is the lifecycle ? They can continue to accumulate indefinitely ?
|
@devmadhuu @sumitagrawl please take another look |
devmadhuu
left a comment
There was a problem hiding this comment.
@ArafatKhan2198 Few comments still unresolved. pls check.
devmadhuu
left a comment
There was a problem hiding this comment.
Thanks @ArafatKhan2198 for improving the patch. Just one minor comment. Rest all LGTM
…tly for large no of records
devmadhuu
left a comment
There was a problem hiding this comment.
Thanks @ArafatKhan2198 . Changes LGTM now.
What changes were proposed in this pull request?
The Recon UI had no way for administrators to export unhealthy container data (Missing, Under-Replicated, Over-Replicated, etc.) at scale. For clusters with millions of containers, any streaming export over a long-running HTTP connection would be killed by network infrastructure (firewalls, load balancers, proxies) before completion.
Solution: Asynchronous Background Export with Queue
Instead of streaming data directly to the browser, this PR implements a server-side background job system that:
Backend Changes
New:
ExportJobmodel (ExportJob.java)A data class representing one export job with fields:
jobId(UUID),userId,state(container state),status(QUEUED → RUNNING → COMPLETED/FAILED)queuePosition,totalRecords,estimatedTotal,progressPercentfilePath(path to TAR on disk),submittedAt,startedAt,completedAt,errorMessageNew:
ExportJobManager.java— the core engineA Guice Singleton that runs for the lifetime of the Recon server:
part001.csv,part002.csv)Archiver.create()intoexport_{state}_{userId}_{shortJobId}.tarCOUNT(*)before the cursor opens to calculateestimatedTotal;totalRecordsincrements livesubmitJob()— prevents race conditions when multiple users submit simultaneouslygetQueuePosition()— walksLinkedHashMap(insertion-order) to return 1-indexed positionContainerEndpoint.java— new REST endpointsQueue-full (429) errors return JSON instead of Jetty's HTML error page.
ContainerHealthSchemaManager.javagetUnhealthyContainersCursor()— jOOQ lazy cursor for streaming DB records without holding them all in JVM heapgetUnhealthyContainersCount()— fastCOUNT(*)used before the cursor opens for progress estimationReconServerConfigKeys.javaNew config keys:
ozone.recon.export.worker.threads(default: 1)ozone.recon.export.directory(default:/tmp/recon/exports)ozone.recon.export.max.jobs.total(default: 10)Frontend Changes (
containers.tsx,container.types.ts)New: Export Tab (tab key
'6')A dedicated Export tab is added to the Containers page alongside Missing, Under-Replicated, etc. It contains:
Submit Controls:
Active Exports table (hidden when empty):
#1,#2...), Progress bar + record countCompleted Exports table (always visible, paginated):
MMM D, HH:mm:ssPolling:
setInterval+useRef— starts when Export tab is opened or a job is submittedError handling:
- 429 queue-full error shows a 6-second toast with the specific message
- All errors show clean messages (no raw HTML from Jetty)
- Guard in
## What is the link to the Apache JIRAfetchTabDatapreventsundefinedAPI calls when Export tab is activehttps://issues.apache.org/jira/browse/HDDS-14913
How was this patch tested?
Log Changes -
CSV_Export_Feature.mp4