On Mon, Jul 26, 2010 at 7:10 PM, David Sitsky <s...@nuix.com> wrote: > During processing.. there might be a number of reasons why we need to > shutdown the indexing process, but perhaps what is unusual is we call > the win32 API TerminateProcess() call rather than System.exit(), for > slightly obscure reasons. When calling exit(), this still calls a > large body of code (for example dll shutdown hooks) which in some > situations, we found could "hang" the exiting process, which was a > problem for us. > > In a sense, this should be no different to killing the process under > Windows using the task manager, or kill -9 on unix systems.
OK. Lucene should be fine after a kill -9 or a TerminateProcess, assuming Windows really does act like Unix and any "committed" IO operations done by the process prior to the kill are in fact committed to the filesystem. > At no time did the machine itself crash, and the disk involved (I'm > told) was a local RAID filesystem. I am guessing the disk has write > caching enabled, but given the machine didn't crash, this shouldn't > matter. Right, the write caching shouldn't matter since the machine didn't go down. > Something else that is slightly unusual is we explicitly call commit() > at certain times to flush indexing work to disk. OK that's fine. > Its interesting in both instances, CheckIndex said there was 1 broken > segment containing 1 document. Yeah that is curious.... I'll try to mull. Any chance you could run with an infoStream set on IndexWriter? Then if this happens again I can pour over that... Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
