Search returns no results


Emerse is up and running, but search is returning no results. In the top left of the Emerse window, I see the number of patients loaded (1,750), but no luck with search. And there is no on-screen error… just 0 results. The application diagnostics report good status for all types.

In catalina.out:

Opening solr connection using url http://localhost:8983/solr/documents

If I curl to that url from the server, I get a basic auth error, and if I turn off basic auth, I get a file not found.

We had a bit of difficulty recently getting Tomcat and Solr to cooperate with regard to the cores. The script to install Solr as a service wanted the cores in /var/solr/data, but from the initial install we were targeting /app/data/solr as the path to the cores. Thus, our lucene.indexPath points to /app/data/solr7

I added the solr user to the tomcat group, and gave read/write/execute permissions on patient, patient-slave, and document directories in /app/data/solr7. Solr can now read these cores.

The search was working when the lucene.indexPath pointed to /var/solr/data, but that’s not where our actual test data was loaded, and so if I point there now, I get the following error in the diagnostics:

MRN 100001398 appears in lucene, but not in SOLR. Are both lucene and SOLR pointing to the same indexes?

Many thanks for whatever help or direction you can provide.


It sounds like you have data in /var/solr/data since when you set lucene.indexPath to that, the diagnostics report there’s an MRN in lucene (ie, the path you set) but not in Solr. So, I’d double-check that you really have data in /app/data/solr7, probably by just making sure the directory is about as large as you’d expect, file-size-wise. Still, I’m guessing you do have data in there since diagnostics doesn’t complain.

The /solr/documents path should return 404; it’s just the base EMERSE is using to make a query. You can do an actual query like:


Which will tell you how many documents are in your index total, and ten sample documents. If that doesn’t return anything, then Solr might be pointing to the wrong place. We set SOLR_HOME to our index path, but if you’ve installed Solr as a service, you might need to do something different. (Are you on Windows?) You can see a better overview of Solr in the admin panel, which will tell you what indexes are loaded and where they are. But, I’m guessing that’s all correct.

So, I’m not sure what the problem is… If you’ve just recently indexed the data, I would restart both Solr and tomcat, since both can have an “old” version of the index files open (the version before documents were indexed). (Solr / lucene can support old consistent views of the index kind of like how databases provide consistent views of tables in a transaction.)

When you do your search, are you doing an All-Patient search with no date constraints? Basically, once you log in, just type something into the input box and hit search? That should go to Solr and return anything that matches. If you have date constraints on, there could be an issue with the Solr field names indexed in Solr vs what EMERSE is using in its query, but it sounds like you have the sample data loaded, so I’d guess all that is configured correctly.


Thank you for your response.

Apparently, a background process ran last night (I see a timestamp from last night in the Patient_List:Update_Date field). So, I guess ActiveMQ kicked off the patient-index-replication? Is it possible to do this manually (I still have to set up the production server, so it might be helpful.)

Also, we’re running on CentOS with Tomcat and Solr running as services.

Again, thank you for your help.


Yes, probably, though it isn’t ActiveMQ but just the scheduler inside EMERSE running in Tomcat.

You should be able to force all the batch processing to happen inside EMERSE’s admin app. Look here:

It can be a bit buggy at times though :frowning:

You can also just force the indexes to re-open by making a get to:


(depending on the port/host you have for EMERSE of course).

Great. Thank you again for sharing your expertise as we continue with this project.