Can we fix NIOFSIndexInput to simply reopen the channel when the exception occurs?
----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: Simon Willnauer [mailto:simon.willna...@googlemail.com] > Sent: Thursday, January 28, 2010 9:52 AM > To: java-dev > Subject: Nasty NIO behavior makes NIOFSDirectory silently close channel > > 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/ClosedByInte > rruptException.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 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
