1991santhu opened a new issue, #1715: URL: https://github.com/apache/iceberg-go/issues/1715
Raised by @laskoviymishka during review of #1640 and deferred as out of scope there. `catalog/hive/lock.go`'s `calculateBackoff` doubles the wait on each attempt: ```go return minWait << attempt ``` Java's `Tasks.exponentialBackoff` uses a scale factor of **1.5**, not 2.0. For a client retrying a contended table lock, the two implementations therefore walk different schedules from the same configuration, and a mixed Go/Java fleet against one metastore backs off at different rates. Filing rather than changing it, because either direction is a behaviour change for existing deployments: - Matching Java (1.5) makes Go clients retry more often and reach the cap later. - Keeping 2.0 is defensible on its own terms, but the divergence should then be intentional and documented rather than incidental. Related: the `[d, 2d]` jitter window in `applyJitter` is also wider than Java's ~10%-of-current-delay jitter. That one is now called out in the doc comment (#1714), but the underlying difference is the same question — how closely should the Go client match Java's retry behaviour against shared infrastructure? -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
