Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1125472

Summary: Ops: Revisit Hibernate Search lock detection
Product: [Retired] Zanata Reporter: Sean Flanigan <sflaniga>
Component: Deployment, UsabilityAssignee: Damian Jansen <djansen>
Status: CLOSED CURRENTRELEASE QA Contact: Zanata-QA Mailling List <zanata-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: developmentCC: dchen, zanata-bugs
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 3.6.2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-07-20 07:31:43 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sean Flanigan 2014-08-01 01:02:41 UTC 
For Hibernate Search's index files, we are now using NativeFSLockFactory, presumably because we upgraded Hibernate Search.  (NB it may not be the default on all platforms.)  NativeFSLockFactory is supposed to delete lock files automatically in case of a crash.

We should check whether Hibernate Search is now smart enough to report lock problems at startup all by itself [1], and if so, we can remove the lock check in ZanataInit.  We should test with (a) two copies of Zanata running (the second one should refuse to run because the locks are live) and (b) with stale lock files when starting Zanata (in which case Zanata should delete the lock and create a new one).  

We should also try killing the Zanata process to check that the native locks are really removed by NativeFSLockFactory as promised.

On the other hand, if we decide to keep the lock check in ZanataInit, we should at least change the error message it generates: as long as the original Hibernate Search process is dead, it should be safe to delete the lock file but keep the index directories, thus avoiding the need to re-index everything.

[1] In the past, there were no error messages from Hibernate Search: the background indexing thread just died or blocked silently, and new objects were not indexed.
Comment 1 Sean Flanigan 2015-07-20 07:31:43 UTC 
ZanataInit no longer prevents the deployment if .lock files are found - in most cases it just outputs an INFO message.  See https://github.com/zanata/zanata-server/pull/562.

Note: I said in the bug report that "as long as the original Hibernate Search process is dead, it should be safe to delete the lock file but keep the index directories, thus avoiding the need to re-index everything", but I'm not sure if that is true or not.  The fact that Hibernate Search now ignores stale locks /suggests/ that it may not be important.  We have recently had complaints that Zanata 3.6.2 was not indexing new changes, but this may have been a misunderstanding.