Fwd: Thread interruption while reading from a ZipFS entry will close the entire FS

[Bruno Ploumhans]

Thanks Alan, I had missed that issue.

There are a few places in NIO with code similar to:
if (channel instanceof FileChannelImpl channel) {
   channel.setUninterruptible();
}
For example, FileSystemProvider.newInputStream or Files.readAllBytes.
This change seems to have been introduced (by you!) in [1] to fix a
similar issue with these functions.

I am inclined to believe that Files.readAllBytes is doing the right
thing, so I would propose 3 fix strategies:
1. Change Files.newByteChannel to call setUninterruptible() on FileChannelImpl.
2. Call setUninterruptible() on FileChannelImpl from ZipFS.
3. Same as 2. but with the addition of a new API method for
setUninterruptible, to expose the same functionality to other FS
implementations.

I think that 2. would be the simplest fix (no new API, no change of
contract), and would not prevent going with 1. or 3. in the future if
desired. Should I work on a patch?

Regards,
Bruno

[1] https://github.com/openjdk/jdk/commit/807c4ae4a378f14b6912fa848eaf59af20b99e22


Le ven. 12 avr. 2024 à 19:49, Alan Bateman <Alan.Bateman at oracle.com> a écrit :
>
>
>
> On 12/04/2024 18:42, Bruno Ploumhans wrote:
>
> Hi,
>
> When reading from a zip file on the disk, ZipFileSystem uses a SeekableByteChannel internally to read from the zip file. Unfortunately, this channel is interruptible, and therefore a single thread interruption while reading from a ZipPath will make the entire ZipFS unusable. This is problematic for long-lived ZipFileSystems that can be used by multiple threads. I suppose that this is a bug?
>
>
> There are a couple of issues on this, JDK-8316882 [1]. We had proposals in the past to allow a FileChannel be created as "uninterruptible" but there wasn't consensus on moving forward on that.
>
> -Alan
>
> [1] https://bugs.openjdk.org/browse/JDK-8316882