Last week I ran into nasty hardly reproducible ChannelClosedExceptions thrown by NIOFSDirectory#readInternal() during term position reading. I had a hard time to figure out what causes the channel to be closed as the IndexReader where I obtained the Indexinput or rather TermPositions from was still untouched and open. Yet I was able to perform actions on any other files except the proximity file. Even more weirdness this only happened after upgrading to 3.0 from 2.3. Yet, it turned out that the case of the problem is Java's FileChannel behavior if the thread is interrupted while a read happens. FileChannel (http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/FileChannel.html) throws an ClosedByInterruptException (http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/ClosedByInterruptException.html) if the any thread is interrupted during an IO operation. This causes the index input to be invalid and puts the IndexReader into an invalid state. Yet, I'm really surprised that this has never occured to somebody else or at least not on the list. This behavior makes the usage of NIOFSDirectory extremely dangerous especially in combination with j.u.c.Future and their cancel capabilities. Since, NIO is the new default for anything except of windows we should at least document this behavior in BIG RED LETTERS or rethink the default. I don't see a way to recover from this internal close without really reopen the IndexReader again but I want to leave this to the discussion.
I was able to isolate the behavior into a testcase and will open an issue soon. The list seemed to be a better place to initially inform people. simon --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
