There is a common problem that is occuring with OpenMRS 1.11.6 installations on Windows, with corrupted lucene indexes error shown in https://gist.github.com/ssmusoke/6f00a2eb6ccd39c1f8031ba386d2bbb3
The installations are running on Java 184.108.40.206.
However at each startup the concept indexes are rebuilt by calling Context.updateSearchIndex() to fix search index rebuilds when concepts are updated via SQL scripts.
Is there any update to core that enables search indexes to be rebuilt when the concept tables change so that we do not have to rebuild the concepts at each startup?
Is there a way to schedule rebuilds of the search indexes automatically.
Is there any option we need to be looking at?
Attached is an image of the startup screen
Could you please list steps to reproduce it?
@raff This error has been reported from field installations and occurrence is increasing.
I am not yet sure of how to reproduce on my local machine, but the current fix has been to delete the lucene folder in the application data directory.
Where are you calling Context.updateSearchIndex()?
It’s only possible to schedule rebuilding the index at next startup by setting search.indexVersion GP to null.
Apparently also Context.updateSearchIndexAsync() was added in 1.12.x to trigger rebuilding the index regardless of the search.indexVersion GP.
@raff I am calling Context.updateSearchIndex() as the first line of the activator for the custom module that configures our EMR instances
Do you set the search.indexVersion GP to null prior to calling Context.updateSearchIndex()? If not, then the index is not rebuilt.
@raff Nope I was not setting the search.indexVersion to null, so let me add that line and will advise on what I find after deploying an update in the field in a few weeks.
Thanks a bunch
I’m sorry I mixed up 2 methods: setupSearchIndex() and updateSearchIndex(). It’s not necessary to set the GP to null when calling updateSearchIndex(). It’s only for setupSearchIndex…
How can I fix this if it is running on CentOs? Please Advise. I have Bahmni running on Centos and our openmrs is down after power cuts.
Can you delete the lucene folder and then run openmrs again?
Thanks a lot Daniel for the reply, just to confirm on that, Lucene folder has indexes subfolder which also has other some 5-7 subfolders. Can you please confirm this location /opt/openmrs/lucene?
Thanks a lot once again for your help
This solution really worked and openmrs is back operational. On CentOs, I deleted ‘‘lucene’’ folder and its subdirectories, its location was /opt/openmrs/lucene.
Much relieved with this fix
KenyaEMR runs on platform 1.12.1 and we experience this problem whenever there is power outage during EMR use which result in corrupted indexes. Whenever this occurs, we delete the lucene folder and restart tomcat and it all works well. We are, however, disadvantaged due to the many installations (approx 500) we support and the workaround is a bit manual. I would like to check the status of the indexes and trigger a rebuild if any is bad.
Could someone point me to the right place to do this? I have noted that this problem is thrown when openmrs starts thus any solution must be within the core. I have tried to play around with Context.startup() in core in vain.
Thanks, and looking forward to any leads. @dkayiwa @mksd @mogoodrich
Does this mean you are ready to upgrade your openmrs platform to the one with the fix?
Thanks, Daniel. We plan to upgrade in the next 5-6 months but would love to even port that fix in the version that we use. I will appreciate any leads.
Just for testing purposes, are you able to reproduce this with the latest version of the platform?
I have looked through the code logic and I haven’t found anywhere any sort of cleanup is done. We are running on version 1.12.1 still.