Home/ Questions/Q 7841685
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T16:09:06+00:00

we recently upgraded to Hibernate Search 4.1 and are getting errors when we run

  • 0

we recently upgraded to Hibernate Search 4.1 and are getting errors when we run our JUnit tests based on the changes hibernate made with regards to locks. When we run Junit tests with the AbstractTransactionalJUnit4SpringContextTests we often see locks left after each test. In reviewing (How to handle Hibernate-Search index recovery) we tried the native locks, but this did not resolve the issue.

We’ve tried out the various locking mechanisms (simple, single, and native) using the default directory provider (Filestore) and regularly see messages like:

build   20-Apr-2012 07:07:53    ERROR 2012-04-20 07:07:53,290 154053 (LogErrorHandler.java:83) org.hibernate.search.exception.impl.LogErrorHandler  - HSEARCH000058: HSEARCH000117: IOException on the IndexWriter
build   20-Apr-2012 07:07:53    org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@target/indexes/Resource/write.lock
build   20-Apr-2012 07:07:53        at org.apache.lucene.store.Lock.obtain(Lock.java:84)
build   20-Apr-2012 07:07:53        at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1108)

or 

build   19-Apr-2012 19:31:09    ERROR 2012-04-19 19:31:09,395 153552 (LuceneBackendTaskStreamer.java:61) org.hibernate.search.backend.impl.lucene.LuceneBackendTaskStreamer  - HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync!

Some of these messages seem to show the lock issue cascading from one test to another, hence the need for the reset, and some may be valid because the tests are testing ‘invalid’ behaviors and how our application reacts to them, but often because of cases like this where the ID is null

build   19-Apr-2012 19:31:11    Primary Failure:
build   19-Apr-2012 19:31:11        Entity org.tdar.core.bean.resource.CodingSheet  Id null  Work Type  org.hibernate.search.backend.PurgeAllLuceneWork

But, regardless, we need to make sure that one test does not effect another.

In reading some of the discussions (email discussion on directory providers) it was suggested that the RAM based directory provider might be a better option, but we’d prefer to use the same provider as we use in production wherever possible.

How should we be resetting HibernateSearch between tests to clean up lock files and reset potential issues where the index is out-of-sync or corrupted? At the beginning of the test suite, we wipe the index directory, is it recommended to wipe it after every test?

thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If you have stale locks in the directory, it means that Hibernate Search wasn’t shut down properly as it certainly will close the locks.

    If you start a new Hibernate SessionFactory in each test, you should make sure it’s closed as well after the test was run:

    org.hibernate.SessionFactory.close()

    (This is often missing in many examples as there are no noticeable problems when forgetting to close a Hibernate SessionFactory, but has never been optional and might leak connections or threads).

    The thread from the Hibernate mailing list you linked to ended up changing the locks to use native handles in Hibernate Search 4.1, so that locks are cleaned up automatically in case the JVM crashes or is killed. But in your case I guess you’re not killing the VM between tests, so you just need to make sure locks are released properly by shutting down the service.

    exclusive_index_use=false hides the problem as the IndexWriter will be closed at the end of each transaction. That makes it slower though, as it’s significantly more efficient to reuse the IndexWriter. The reason you have this issue after upgrading to Hibernate Search 4.1 is that this option was changed to true by default. But even then, you should still close it properly.

    • 0