wombatu-kun opened a new pull request, #9098: URL: https://github.com/apache/paimon/pull/9098
### Purpose Closes #9005. `CachingSeekableInputStream.getRemoteStream()` created the remote stream into a plain field behind a bare null check, but it is reached concurrently: `VectoredReadUtils.readVectored` fans `preadFully` out over `IO_THREAD_POOL`, and on a cold block cache every task finds the field null. Several then call `fileIO.newInputStream(path)`, and every assignment but the last is orphaned. It also returned the field rather than the stream it had just created, so a reader could get another thread's stream, or `null` if `close()` interleaved. Reachable on default options: `local-cache.whitelist` defaults to `meta,global-index`, and `NativeVectorGlobalIndexReader` reads global index files with parallelism 32 and no sequential fallback. The lazy init now runs under a private lock with a double check. `close()` takes no lock, so it never waits behind an in-flight open: it sets a `closed` flag and detaches the stream with `getAndSet`, and the opener re-reads the flag after publishing, so exactly one of the two ends up owning it. Reads after `close()` throw instead of silently reopening, guarded on `read`, `read(byte[],int,int)` and `pread` the way `MultiPartUploadTwoPhaseOutputStream` guards `write` and `flush`. `fileSize()` gets the same guard, since it had the same unguarded lazy init one layer up and issued one `getFileStatus` per fan-out thread. ### Tests Six tests in `CachingFileIOTest`, five of them red without the fix. The concurrent ones force the interleaving with a delegate that parks inside `newInputStream`, instead of relying on timing. -- 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]
