I'm getting these errors on our indexing server (using the JMS clustering mechanism). Any ideas what's going on and how I can fix this? I did just move the indexes directory yesterday from tomcat's bin dir to /mnt/indexes/base, then I put a symbolic link from tomcat/bin/indexes -> /mnt/indexes/base. It would seem to make sense that it has something to do with this, but I had shut down tomcat (which runs Spring and my MDP doing the JMS reading & indexing) and didn't start getting these errors until many hours after the move...

ERROR [pool-1-thread-1] FSMasterDirectoryProvider - Unable to synchronize source of /mnt/indexes/base/com.example.Person
java.io.FileNotFoundException: indexes/com.example.Person/_11k7.cfs (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at org.hibernate.search.util.FileHelper.copyFile(FileHelper.java:157)
at org.hibernate.search.util.FileHelper.synchronize(FileHelper.java:148)
at org.hibernate.search.util.FileHelper.synchronize(FileHelper.java:132)
at org.hibernate.search.store.FSMasterDirectoryProvider$CopyDirectory.run(FSMasterDirectoryProvider.java:225)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
ERROR [pool-1-thread-1] FSMasterDirectoryProvider - Unable to synchronize source of /mnt/indexes/base/com.example.Person
java.io.FileNotFoundException: indexes/com.example.Person/_1oen_1db.del (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at org.hibernate.search.util.FileHelper.copyFile(FileHelper.java:157)
at org.hibernate.search.util.FileHelper.synchronize(FileHelper.java:148)
at org.hibernate.search.util.FileHelper.synchronize(FileHelper.java:132)
at org.hibernate.search.store.FSMasterDirectoryProvider$CopyDirectory.run(FSMasterDirectoryProvider.java:225)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
ERROR [pool-1-thread-1] FSMasterDirectoryProvider - Unable to synchronize source of /mnt/indexes/base/com.example.Person
java.io.FileNotFoundException: indexes/com.example.Person/_2crt.fdt (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at org.hibernate.search.util.FileHelper.copyFile(FileHelper.java:157)
at org.hibernate.search.util.FileHelper.synchronize(FileHelper.java:148)
at org.hibernate.search.util.FileHelper.synchronize(FileHelper.java:132)
at org.hibernate.search.store.FSMasterDirectoryProvider$CopyDirectory.run(FSMasterDirectoryProvider.java:225)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

Hi,

based on the name /mnt/indexes/base seems to be a mounted directory. What type of shared filesystem protocol are you using. Some people reported problems with Lucene and NFS (not sure whether this still applies though). It might also depend on the version of Search (and hence Lucene) you are using.
Another thought - are you sure the shared file system is working properly? No errors there? Any network problems maybe?

--Hardy

Sorry I should've been more clear on the directory. I moved it to /mnt/indexes/base simply because that partition had a ton more space and I had /mnt/indexes/source. This is a local hard drive. It is not a shared filesystem, though /mnt/indexes/source is exported so other servers can mount it for obvious reasons.

I continue to get these FileNotFoundExceptions periodically. I'm worried that I'm missing parts of our search, though manually testing everything seems fine. We were using Hibernate Search 3.1.1 and then upgrade to 3.2CR1 (and now final). So I figured the first couple of these errors were due to that. But it's been a while and we still see these.

I just rebuilt our entire index (though without deleting all the lucene files first) and got about 30 of these exceptions. Should I rebuild from scratch, deleting the index first? Or is that pointless and I shouldn't have any problems as long as there weren't any filesystem problems during this (I very much doubt there are underlying filesystem problems)?

Is it always the same error you are seeing? The error occurs when the master switches the index directories.
The Lucene version between Search 3.1.1 and 3.2.CR1 has changed from 2.4 to 2.9. For this reason I would have recommended to rebuild the indexes from scratch deleting the old indexes. If the exceptions still occur there might be still another issue.

--Hardy