Search before asking
Paimon version
master @ d3b62af
Compute Engine
Engine-agnostic (Azure FileIO adapter)
Minimal reproduce step
Use a single AzureFileIO instance to access paths under two different authorities (e.g. abfs://c1@acct1.dfs.core.windows.net/... and abfs://c2@acct2.dfs.core.windows.net/...). HadoopCompliantFileIO.getFileSystem() (paimon-filesystems/paimon-azure-impl/.../azure/HadoopCompliantFileIO.java line 44, 109) caches the first authority's FileSystem in a single instance field fs and returns it regardless of the requested authority. The sibling oss/s3/gs/obs (#8589) already cache by authority in a Map<String, FileSystem>.
What doesn't meet your expectations?
Expected: each authority is served by its own FileSystem. Actual: after the first access, all read/write/delete/rename for other authorities are misrouted to the first authority's FileSystem, causing silent reads/writes against the wrong storage account.
Anything else?
N/A
Are you willing to submit a PR?
Search before asking
Paimon version
master @ d3b62af
Compute Engine
Engine-agnostic (Azure FileIO adapter)
Minimal reproduce step
Use a single
AzureFileIOinstance to access paths under two different authorities (e.g.abfs://c1@acct1.dfs.core.windows.net/...andabfs://c2@acct2.dfs.core.windows.net/...).HadoopCompliantFileIO.getFileSystem()(paimon-filesystems/paimon-azure-impl/.../azure/HadoopCompliantFileIO.javaline 44, 109) caches the first authority'sFileSystemin a single instance fieldfsand returns it regardless of the requested authority. The sibling oss/s3/gs/obs (#8589) already cache by authority in aMap<String, FileSystem>.What doesn't meet your expectations?
Expected: each authority is served by its own
FileSystem. Actual: after the first access, all read/write/delete/rename for other authorities are misrouted to the first authority'sFileSystem, causing silent reads/writes against the wrong storage account.Anything else?
N/A
Are you willing to submit a PR?