NIO channels could optimize buffer-invalidation on seeks

[ryan-williams]

BlobReadChannel dumps its buffer on any seek, therefore so does CloudStorageReadChannel.

This causes unexpected/pathological behavior, e.g. in hadoop-bam/spark-bam where the read pattern is roughly "read 100 bytes, rewind 99 bytes, repeat 1000x"; basically the same 2MB is fetched over the network at every iteration.

spark-bam uses a CachingChannel abstraction that LRU-caches blocks of the underlying channel, which fixes this.

Just wanted to call out this "gotcha"; might be worth fixing here.

[lbergelson]

@jean-philippe-martin This is a slightly different use case than the buffering/prefetching we do in gatk, but maybe it could be addressed as part of the work on porting that.

[jean-philippe-martin]

It'd probably be best to at least first port the prefetching as is, but yes: the prefetcher does optimize buffer invalidation on seeks so if you are using it then you're good.

[lbergelson]

The weird bit here is that this query moves backwards slightly from the original fetch. Does the current pre-fetcher handle that correctly? I had thought it only supported forward motion and would probably invalidate the buffer if it moved backwards. I could just be wrong though.

[jean-philippe-martin]

The prefetcher uses blocks. So long as the backward read is within the block, we'll be able to serve data. If you go far back enough that we don't have that data anymore we have to fetch it again of course.

So for example if you use 1 million bytes blocks, and you seek to 1'000'300, read something, and then seek to 1'00'020, you'll be good because you're in the same block. That's just a random number for explanation, of course.

[lbergelson]

Ah, sounds good then.

[jean-philippe-martin]

Pull request #3054 introduced SeekableByteChannelPrefetcher into nio, which does smart buffering (also, prefetching). It retains buffers on seeks so closes this issue (even though it's a tad different, as @lbergelson pointed out). I'd close this issue if I could.