On Thu, Jan 28, 2010 at 8:24 AM, Michael McCandless <luc...@mikemccandless.com> wrote: > 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!
All of these options suck.... (venom directed at Sun... not you Mike :-) Lucene is used embedded in so many places - it would be OK for Lucene itself not to use Thread.interrupt() or Future.cancel(), but *any* other component or application that happens to include Lucene? And I know that Solr already uses Future.cancel() - which means we need to go carefully look to see that nothing that could be canceled calls lucene APIs that could read/write the index. Other options include hard hacks like bytecode modification to stop the close (assuming what does the code is even in Java). In the meantime - perhaps Lucene should revert and not use NIOFSDir by default? -Yonik http://www.lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
