lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Williams <>
Subject Re: IndexSearcher hanging on to old index files in Windows
Date Fri, 29 Apr 2005 18:57:01 GMT
Monsur Hossain wrote:

>"The process cannot access the file because it is being used by another
>It then sticks the filename in Lucene's "deletable" file to be deleted at
>some later time.  As a sanity check I used Process Explorer to delete the
>file handle before running the incremental index, and it worked fine.
>Since this is happening in both .NET and Java, I'm assuming its Windows
>specific.  I don't know much about Windows low-level file management, but
>I'm going to keep digging into this issue further.  Does anyone have any
>expertise in this area, or know why this behavior is different in Windows
>vs. Linux?
Yes, Windows won't allow you to delete a file that is separately open. 
Linux will because it can disconnect the inode. The actual data blocks 
in the file won't be deleted until nobody is accessing them. Windows 
doesn't have that kind of garbage collection in the OS itself.

I'm confident you don't have to worry about that. As mentioned earlier, 
I ran a large scalability benchmark on Windows and everything did end up 
properly. I ran this test a little differently than letting the 
IndexSearcher get garbage collected. Instead, I explicitly closed the 
searcher (reader) and reopened it periodically. I used explicit 
synchronization involving counts of searches in process, such that when 
it can time to refresh the searcher, new searches would wait until the 
searcher was refreshed and the refresh operation would wait until the 
searches already in progress had completed. This did not seem to add any 
significant delays to search times even on a very large index.

The garbage collection approach should work as well.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message