Monsur Hossain wrote:
"The process cannot access the file because it is being used by anotherYes, 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.
process."
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?
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.
Chuck
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
