I have a master/slave setup, with a single master and slave instance running over JMS on the SAME localhost (no NFS involved). My master instance, in addition to processing index-update requests from the queue, also runs a task on a cron schedule to regularly purge and rebuild the indices from the latest db data. This all seems to work fine.

However, every so often, on the slave side, I get the following error:



I looked at the Hibernate search code and all it's doing is attempting a file.delete on the corresponding handle. But for some reason, that file is locked even though the slave instance has exclusive access to it. Could this be a case of the initial copy from the source not properly releasing the lock? Anyone else seen this?

Windows XP SP3 / Hibernate Search 3.3 Beta2 / Lucene 3.0.2

Michael

This could be Windows holding a file lock longer that it should. Deleting files on Windows is always harder than on a Unix based system. The error most likely comes from the synchronization code when the new master index gets copied into the new slave index directory. The process tries to delete in the new slave index directory which don't exist in the new master index. Even if such a deletion fails it will not have a direct impact on the result. In the worst case the file gets copied on a later switch. It will however not be used by Lucene once the index switch occurs.
Do you have any reason to believe that an index corruption occurs? Watch the file across multiple index switches. I am pretty sure it will disappear. Maybe we should reduce the log level in this case!?

--Hardy

Thanks, Hardy. I have no reason to think the source index is corrupted. If what you're saying is true, it would be nice to have the log change to a warning so my sys admin doesn't freak out.