There's a corrupt index exception thrown when opening the searcher. The rest of the files of the segment are OK. Meaning the problem has occurred in writing the bit vector well after the segment has been written. I'm guessing we're simply not verifying that the BV has been written fully/properly, and that we're going on to commit the segment infos anyways.
On Wed, Oct 13, 2010 at 10:15 AM, Michael McCandless <luc...@mikemccandless.com> wrote: > I'm not certain whether we test this particular case, but we do have > several disk full tests. > > But: are you seeing a corrupt index? Ie, exception on open or on > searching or on CheckIndex? > > Or: do you see a disk-full exception when writing the del file, during > indexing, that does not in fact corrupt the index (this is of course > what I hope you are seeing ;) ). > > Mike > > On Wed, Oct 13, 2010 at 11:37 AM, Jason Rutherglen > <jason.rutherg...@gmail.com> wrote: >> We have unit tests for running out of disk space? However we have >> Tomcat logs that fill up quickly and starve Solr 1.4.1 of space. The >> main segments are probably not corrupted, however routinely now, there >> are deletes files of length 0. >> >> 0 2010-10-12 18:35 _cc_8.del >> >> Which is fundamental index corruption, though less extreme. Are we >> testing for this? >> >
