Tomcat parallel deployment and locked Lucene index

Tomcat 8 supports parallel deployment which means two versions of the same application can be active and Tomcat handles connections: users having a session are redirected to old app version and new users with no session are redirected to new app version. Once all sessions from old app are closed / expired, that version can be removed.
Doing deploy that way you’re able to have zero downtime but… Here comes Lucene with lock files making it impossible.

I did a setup on my Ubuntu server on Virtual Box and what happens is that first application (old) creates lock file for Lucene.
When new version is deployed, it tries to open Lucene indexes and it finds lock file and this is the end of the story with parallel deploy (for me).

I use Hibernate for almost any query I have on my project except for autocomplete which is pretty complex and I implemented it as a stored procedure to be able to use LIKE operators in a complex query that is used by my custom autocomplete.

Is there any other way to use parallel deploy with Hibernate Search / Lucene?
The idea that comes to my mind is to add some admin option (API REST endpoint) to put old application into read only mode which would disable any writes to DB & Lucene index and that would release lock file (my knowledge of Lucene is not good enough to be sure if this is possible) - after that lock, the deploy should be possible and Lucene could be used by new app.

And thoughts on this?

Thanks!

Hey @horvoje

Thanks for reaching out. This is an interesting use case. Currently, the directory locking happens when the backend “starts”, so you won’t be able to switch it while the app runs. But… there’s a config property for the locking strategy hibernate.search.backend.directory.locking.strategy.

You probably could disable locking from the start (Hibernate Search 7.2.3.Final: Reference Documentation)

hibernate.search.backend.directory.locking.strategy = none

but you must make sure that the “first” app entirely disables any writes before the “second” one starts deploying… otherwise the index could get corrupted, and you’ll end up reindexing all your data…

We have this improvement in the backlog for the read-only indexes HSEARCH-5261 and I’m wondering whether we could allow the switch of the read/write mode at runtime…

1 Like

Thanks a lot! That really helps, at least at theoretical level because I’m writing this “thank-you reply” before trying it on my development environment. :slight_smile:

In my case it will be pretty easy to avoid writes because only writes I have are web-form triggered, when user submits a suggestion to add a new product to the catalog. Everything else is triggered from admin interface and that would be only me. LoL

But it would be great to have some kind of API to call to do it at some higher level rather than implementing it on my own - that’s my thought for all Hibernate Search users more than for myself.

Thanks again!

1 Like