LockObtainFailedException with gradle test after v6.1 migration from 5.x

After migration from HS 5 to HS 6.1 , i got some error like this :
DtbTest > testCheckoutWithBonus FAILED
org.hibernate.search.util.common.SearchException at DtbTest.java:1112
Caused by: org.apache.lucene.store.LockObtainFailedException at DtbTest.java:1112
when i launch all my tests cases from gradle.

it’s working very well with v5 when i launch to job with jenkins :

  • recreate index from db test with massIndexer
  • launch all the other test with transactional context.

It’s seem a previous test does’nt clean his lock after index modification ( and rollback of them )

( tests are not running from exactly the same context )

if someone got an idea …


This generally indicates you’ve started Hibernate Search multiple times in parallel, using the same indexes. Hibernate Search expects to get exclusive use of indexes.

This answer on stackoverflow might help: Spring Boot Integration Test failes due to lucene lock when using Hibernate Search - Stack Overflow

all is sequential, i never launch something in parallel.

i take care to reindex before launching all the tests.

with hibernate search 5, all is ok.

i got this with v6.

and it’s difficult to find which test put a lock.

maybe it’s because a change of context between group of test ( for exemple):

  • x tests are launching with webcontext
  • y test are launching with integrationContext

and between this 2 context, second group start before the first clean all correctly.

i don’t know how to check for lock before starting and wait a little bit if necessary

That’s possible.

It would probably make more sense to make sure you never start the application twice in parallel. I don’t even know which framework you’re using though, and even if I did I’m probably not familiar enough with it to help with that. I could recommend moving your integration tests to a dedicated Maven/Gradle module, but who knows if it’s a good fit for your application.

Leaving this in case you need to investigate more:

If you’re getting this exception, it means something holds a lock to your indexes when Hibernate Search starts and tries to acquire the lock. So either:

  1. you are launching two Hibernate Search instances (or more) in parallel
  2. OR something else than Hibernate Search is holding that lock (unlikely, but possible if you have code using Lucene APIs directly)
  3. OR a previous instance of Hibernate Search was not closed properly or failed to shutdown, leaving the lock on one or more indexes.

Hibernate Search 5 might have seemed to work properly (though there were problems, just hidden ones) if:

  • You are in case 1 or 2 and you were using the configuration property exclusive_index_use, which is no longer available in Hibernate Search 6 due to it harming performance and being a risk to data integrity.
  • You are in case in case 1 or 2 and were using a specific configuration of locking in Hibernate Search 5, and are now using a different one (that does not work well) in Hibernate Search 6.
  • You are in case 3 and Hibernate Search 6 shutdown fails somewhere Hibernate Search 5 didn’t, but the exception is swallowed/silenced so you didn’t notice it.
  • You are in case 3 and your development environment is corrupted somehow. Try erasing all index files from the filesystem manually (you’ll lose that data).

I can’t help much more than that without more information. So, either:

  • provide the detailed stacktrace and a reproducer
  • or try to determine if you fall in one of the scenarios above, and if so which one, and provide more information.

i’m using this framework :

  • springBootVersion = ‘2.7.7’
  • ehcacheVersion = ‘2.10.4’
  • hibernateVersion = ‘5.6.12.Final’
  • hibernateSearch =‘6.1.7.Final’
  • luceneVersion = ‘8.11.1’

my config is just :

hibernate.search.backend.directory.root = /opt/lucene/junit

i clean and build all the index before starting the tests.

i’m sure that:

  • i’m not launching 2 or more instance.
  • i’m only using hibernate search ( no direct lucene api call )

i think i’m in the case 3 ( or something similar like a rollback is not terminated when another test contest is launched )

in my investigation, i found another problem, i got a test which not rollback properly the index, so another test failed because the index does’nt have the good information.
( i try to find which one but same thing then the lock problem, it’s working very well with v5 )

i will try to group all tests with the same context in a same root package and launching then separately

i found the responsable of my failed test ( not the lock problem but the data modified between test ) :

  • i launch 2 test class ( same context ) this gradle

  • first class modify data ( all the test methods are with @transactional )

  • second class check some data ( tests fails because of the 1st class modification )

it seems rollback between test not working with v6.

maybe i need to put something on “after” or “before” code ?

( i got same problem if i launch the 2 test class with junit in eclipse : the first class does’nt rollback data modifications )

Nor does it work with Hibernate Search 5, since testing integration is not a Hibernate Search feature.

If you were rolling back changes you applied to an index, you were doing it explicitly, most likely by purging the indexes or purging you database and running the mass indexer.

One place to do this would be before/after methods, yes, though with spring it can be more subtle (and more complicated).

I already described other solutions in the link I gave you yesterday.