Bummer. So the only viable workarounds are 1) don't use Thread.interrupt (nor, things like Future.cancel, which in turn use Thread.interrupt) with NIOFSDir, or 2) we fix NIOFSDir to reopen the channel AND the app must make a deletion policy that keeps a commit alive if any reader is using it. Or, 3) don't use NIOFSDir!
Mike On Thu, Jan 28, 2010 at 7:29 AM, Simon Willnauer <[email protected]> wrote: > On Thu, Jan 28, 2010 at 12:43 PM, Michael McCandless > <[email protected]> wrote: >> On Thu, Jan 28, 2010 at 6:38 AM, Uwe Schindler <[email protected]> wrote: >> >>> So I checked the code of NIOFSIndexInput, my last comment was not really >>> correct: >>> NIOFSIndexInput extends SimpleFSIndexInput and that opens the RAF. In the >>> ctor RAF.getChannel() is called. The RAF keeps open until the file is >>> closed (and also the channel). >>> >>> So it's really simple to fix in my opinion, just call getChannel() again on >>> this exception. Because the RAF should still be open? > > Short answer: > public final FileChannel getChannel() { > synchronized (this) { > if (channel == null) > channel = FileChannelImpl.open(fd, true, rw, this); > return channel; > } > } > > this is not gonna work I tried it before. The RandomAccessFile buffers > the channel!! > > simon >> >> I think we need a definitive answer on what happens to the RAF when >> the FileChannel was closed by Thread.Interrupt. Simon can you test >> this? >> >> Mike >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
