There is a common problem that is occuring with OpenMRS 1.11.6 installations on Windows, with corrupted lucene indexes error shown in OpenMRS Startup Error - Lucene · GitHub
The installations are running on Java 1.7.0.79.
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.
Question:
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.
@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.
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…
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.
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, 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.