How to handle Hibernate-Search index recovery?

Question

When an application server exits unexpectedly, Hibernate Search can not do a graceful shutdown of Lucene. Leaving write.lock files behind in each index directory. That is of course quite normal. But - the lock files also remain after restarting the application. Which causes lock timeout exceptions at some time.

My question is whether there is a usual way to handle the recovery.

What comes first at mind would be to check for the presence of write.lock files. If one is found, they are removed and all indices are rebuilt. But maybe Hibernate-Search does this automatically when properly configured ?

Nobody had to deal with write.lock files before ? – Jan Goyvaerts Mar 20 '12 at 09:16 — Jan Goyvaerts, Mar 20 '12 at 09:16

score 3 · Answer 1 · answered Mar 31 '12 at 15:41

if Hibernate Search were to remove lock files at boot, it might risk to destroy your index if by mistake you configured two applications to run on the same index. Hence not deleting the lock file is the purpose of the lock.

Still, we realized this was annoying: if you can use the Native LockFactory ( http://docs.jboss.org/hibernate/search/4.1/reference/en-US/html_single/#search-configuration-directory-lockfactories ) even a crashed / killed JVM will release the lock files.

If you upgrade to latest versions, Native is used by default if the detected platform is considered safe enough.

How to handle Hibernate-Search index recovery?

1 Answers1

Linked