Hi Guys,
I have a nighly job that does batch indexing, now the server that does the batch indexing was restarted while a batch index job was in progress. This had the effect that the "write.lock" file still existed in the index directory and was never removed.

Fast forward to the batch job running again and I see something i wouldnt have expected........The nightly batch job when just looking in the log files looks like it has run just fine, however this is not true. When i take a closer look at the timestamps of the index i can see that they are from the day before and that in actual fact nothing was written to disk from the latest job although the log files give the illusion that the job ran perfectly. What i would have expected to happen is that the job when trying to acquire the write lock would throw a timeout exception if it failed to acquire the write lock after a certain period of time or simply just block until it could acquire the write lock. However it does neither and the job carries on as if all is well.


Is this expected normal behaviour for HS??

Cheers,
LL

It was not meant to work like that, there's an open issue about the backend not propagating exceptions. Lucene doesn't log anything, and the backend works in a threadpool separated from the main app, so I/O or lockTimeout exceptions are not currently propagated. The exception will kill the current thread, but the threadPool will silently spawn a new one.

http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-421
It's scheduled for the next beta, amin-mc is working on it.

On the locking problem, you could consider the NativeFSLockFactory which will cleanup locks when crashing:
http://wiki.apache.org/lucene-java/AvailableLockFactories

Ok thanks for the info Sanne.