atovk opened a new pull request, #11042:
URL: https://github.com/apache/gravitino/pull/11042

   ### What changes were proposed in this pull request?
   
   This PR adds an OSS metadata fast-fail path in `IcebergCatalogWrapper`:
   
   - Before `loadTable` enters Iceberg's full catalog load path, use 
`SupportsMetadataLocation` to get the table metadata file location.
   - For `oss://` metadata locations with a configured Iceberg `FileIO`, check 
`newInputFile(location).exists()` first.
   - If the OSS metadata file is missing, `loadTable` throws 
`NoSuchTableException` and `tableExists` returns `false` without calling 
`catalog.loadTable`.
   - Add regression tests that verify missing OSS metadata does not enter the 
catalog load path.
   
   ### Why are the changes needed?
   
   A stale Iceberg catalog entry can point to an OSS metadata file that has 
already been removed. In that case, Iceberg's Aliyun OSS metadata read path may 
spend a long time retrying `NoSuchKey` before the failure surfaces. Gravitino 
table operations hold tree locks while dispatching those catalog calls, so the 
retry loop can make UI/API table operations appear stuck and can block related 
operations behind the same lock path.
   
   Using the OSS `exists()` path lets Gravitino detect the missing metadata 
file before entering Iceberg's metadata read retry loop and return the normal 
no-such-table result quickly.
   
   Fix: #11039
   
   ### Does this PR introduce _any_ user-facing change?
   
   No API or configuration changes.
   
   For stale OSS-backed Iceberg table entries whose metadata file is already 
missing, table load/existence checks now fail fast with the existing 
no-such-table behavior instead of waiting for the full Iceberg metadata read 
retry loop.
   
   ### How was this patch tested?
   
   - JDK 17: `./gradlew --no-daemon --max-workers=1 
:iceberg:iceberg-common:test -PskipITs`
   - JDK 17: `./gradlew --no-daemon --max-workers=1 
:iceberg:iceberg-rest-server:test -PskipITs`
   


-- 
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]

Reply via email to