Lucene write.lock error on translation save
Activity
Show:
Oytun Tez 28 January 2018 at 21:21
Oytun Tez 28 January 2018 at 21:17Edited
We are disabling the lock strategy for now from Hibernate Search until we figure this out (hibernate.search.default.locking_strategy = none). Definitely feels like we are leaving something open. This may be due to Docker, but "simple" locking is exactly for this purpose, it works well with NFS (compared to "native").
Duplicate
Details
Details
Assignee
Unassigned
UnassignedReporter
Oytun TezTested Version/s
None
Priority
unspecifiedMore fields
Time tracking
More fields
Time trackingCreated 28 January 2018 at 21:14
Updated 29 January 2018 at 01:48
Resolved 29 January 2018 at 01:48
We are observing a Lucene write.lock error in
Tried making the method Transactional, even though the Bean is Transactional, thinking this could help flush at the end. Didn't help.
The new entity in TextFlowTargetDAO#getOrCreateTarget was not persisting (commented out), which is understandable. Persisted the new object, didn't help.
Lock error is thrown after translate() method is run. Can't tell if this is another thread, but I assume so, the exception log doesn't tell me which thread this is thrown in. I worked with DEBUG on for multiple packages, couldn't find a good clue.
I am suspecting of the events fired in translate() method.
Last log before error: [org.hibernate.search.indexes.spi.DirectoryBasedIndexManager] (default task-1) Sending work to backend of type class org.hibernate.search.backend.impl.lucene.LuceneBackendQueueProcessor
Well... Of course, removing @Indexed from HTextFlowTarget basically sweeps it under the carpet This may also conflict with TranslationMemoryServiceImpl – hopefully not (haven't tested yet)
We encountered very similar errors for all entities that are @Indexed. Attached some logs.
Any ideas?