Bug 1125472 - Ops: Revisit Hibernate Search lock detection
Summary: Ops: Revisit Hibernate Search lock detection
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Zanata
Classification: Retired
Component: Deployment, Usability
Version: development
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Damian Jansen
QA Contact: Zanata-QA Mailling List
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-01 01:02 UTC by Sean Flanigan
Modified: 2015-07-20 07:31 UTC (History)
2 users (show)

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


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1244612 None None None Never

Internal Links: 1244612

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.


Note You need to log in before you can comment on or make changes to this bug.