deepakpanda93 commented on issue #15742: URL: https://github.com/apache/hudi/issues/15742#issuecomment-5393798158
This issue was reviewed as part of the JIRA-migrated backlog triage and is being closed as fixed - with one correction to the record. **The commit previously cited for this (`ffa4ca6f71`) is not the fix and is not on master.** Comparing it against master returns `diverged` (`behind_by=46`); it is the PR's branch tip rather than an ancestor of master. Verifying by that SHA would find nothing. **The work did land, under a different JIRA key.** PR #12804 (*"[HUDI-8988] Implement retry logic for all HTTP calls to timeline server including remote file system view and markers"*) merged on 2025-02-20 as `85dff5cf785f`, and that merge commit is contained in `release-1.1.0`, `release-1.2.0` and `master` (`ahead`, `behind_by=0` for all three). It is directly on the reported path - the PR changes `hudi-client-common/.../table/marker/TimelineServerBasedWriteMarkers.java`, the class in the `SocketTimeoutException` stack here. Still present on current master, now in the shared client rather than the marker class: ```java // TimelineServiceClientBase.java:59 return (retryHelper != null) ? retryHelper.start(() -> executeRequest(request)) : executeRequest(request); ``` with `TimelineServerBasedWriteMarkers` routing through it at `:87`, `:98`, `:109`, `:122` and `:174`. One caveat worth stating: this is mitigation by retry rather than removal of the timeout cause. A genuinely overloaded timeline server can still exhaust the retries - if that is seen, please open a new issue rather than reopening this one. Closing as fixed in **1.1.0**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
