On Mon, Oct 26, 2009 at 2:50 PM, Michael McCandless < luc...@mikemccandless.com> wrote:
> On Mon, Oct 26, 2009 at 10:44 AM, Peter Keegan <peterlkee...@gmail.com> > wrote: > > Even running in console mode, the exception is difficult to interpret. > > Here's an exception that I think occurred during an add document, commit > or > > close: > > doc counts differ for segment _g: field Reader shows 137 but segmentInfo > > shows 5777 > > That's spooky. Do you have the full exception for this one? What IO > system are you running on? (Is it just a local drive on your windows > computer?) It's almost as if the IO system is not generating an > IOException to Java when disk fills up. > Index and code are all on a local drive. There is no other exception coming back - just what I reported. > > > I ensured that the disk space was low before updating the index. > > You mean, to intentionally test the disk-full case? > Yes, that's right. > > > On another occasion, the exception was: > > background merge hit exception: _0:C1080260 _1:C139 _2:C123 _3:C107 > _4:C126 > > _5:C121 _6:C126 _7:C711 _8:C116 into _9 [optimize] [mergeDocStores] > > In this case, the SegmentMerger was trying to open this segment, but > on attempting to read the first int from the fdx (fields index) file > for one of the segments, it hit EOF. > > This is also spooky -- this looks like index corruption, which should > never happen on hitting disk full. > That's what I thought, too. Could Lucene be catching the IOException and turning it into a different exception? > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > >
