wombatu-kun opened a new issue, #9006:
URL: https://github.com/apache/paimon/issues/9006

   ### Search before asking
   
   - [X] I searched in the [issues](https://github.com/apache/paimon/issues) 
and found nothing similar.
   
   ### Paimon version
   
   master, 142f8239b
   
   ### Compute Engine
   
   Engine independent.
   
   ### Minimal reproduce step
   
   Found by code inspection rather than from a failing job. Read a row format 
file whose tail is truncated, or whose footer is corrupt, so that footer or 
block index parsing throws.
   
   ### What doesn't meet your expectations?
   
   `RowFormatReaderFactory.createReader` opens the stream first and only 
transfers ownership to `RowFormatReader` on the last line:
   
   ```java
   SeekableInputStream in = fileIO.newInputStream(path);
   
   int tailSize = (int) Math.min(TAIL_PREFETCH_SIZE, fileSize);
   long tailOffset = fileSize - tailSize;
   in.seek(tailOffset);
   byte[] tailBuf = new byte[tailSize];
   IOUtils.readFully(in, tailBuf);
   
   RowFileFooter footer = RowFileFooter.readFrom(tailBuf, tailSize - 
RowFileFooter.FOOTER_SIZE);
   
   RowBlockIndex blockIndex;
   ...
       blockIndex = RowBlockIndex.readFrom(in, footer.indexOffset, 
footer.indexLength);
   
   return new RowFormatReader(in, path, footer, blockIndex, rowType, 
projection, context.selection());
   ```
   
   There is no `try` / `catch` anywhere in the method, so a throw from 
`in.seek`, `IOUtils.readFully`, `RowFileFooter.readFrom` or 
`RowBlockIndex.readFrom` leaves `in` open with no owner. Scanning a set of 
files where several are corrupt leaks one stream per file.
   
   ### Anything else?
   
   Same interaction as the sibling report on `CachingSeekableInputStream`: with 
the lifetime tracking added in #8962, a stream that is never closed holds its 
lease forever, so that entry's `FileIO` is never released. That matches today's 
behaviour rather than regressing it, but it does keep the fix from reaching the 
affected entries.
   
   Fix shape: close `in` before rethrowing.
   
   ### Are you willing to submit a PR?
   
   - [X] I'm willing to submit a PR!
   


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