Repository navigation
[client] Refactor metadata cache and async updating mechanism and retry mechanism in client side #483
Description
Search before asking
- I searched in the issues and found nothing similar.
Motivation
Currently, the implementation of metadata cache (Cluster) and updating mechanism (MetadataUpdater) on the client side is not very sophisticated. It lacks the general retry mechanism (#480), the time out for UpdateMetadata request is too short to cause job failover (#311), cause job failover when a new partition created (#288).
Solution
This issue aims to introduce a new design of metadata cache and updating mechanism, to resolve above problems.
Anything else?
No response
Willingness to contribute
- I'm willing to submit a PR!
Activity
swuferhong commentedon Jun 5, 2025
Note: we need to refactor coordinatorService#getTableMetadata() and TabletServerMetadataCache#getPartitionMetadata() in order to avoid get table assignment info from zk while no table assignment in server cache.
[-]Refactor metadata cache and async updating mechanism in client side[/-][+][client] Refactor metadata cache and async updating mechanism and retry mechanism in client side[/+]wuchong commentedon Feb 12, 2026
For reference: #479 introduced a
AdminDriverfor retry mechanism.chore: skip duplicate pyfluss build in Python CI (apache#483)
chore: skip duplicate pyfluss build in Python CI (#483)