Thursday, August 28, 2008

On running multiple instances of OpenMRS on the same server

I couldn't find a good place for this on the OpenMRS wiki, so I decided to add it here. I will add this post to the wiki once it's completed and ready to be posted.

To setup multiple instances of OpenMRS, follow this general procedure:
  1. Checkout the latest source code from Subversion
  2. Create separate instances of your database (i.e. openmrs1, openmrs2)
  3. Create separate instances of your OpenMRS runtime file (i.e openmrs1-runtime.properties)
  4. Build an instance of the WAR file
  5. Rename openmrs.war to openmrs1.war
  6. Copy the openmrs1.war to openmrs2.war
  7. Modify runtime properties to point to correct database
  8. Copy openmrs1.war, openmrs2.war to Tomcat webapps
  9. Start tomcat
If you run multiple instances of OpenMRS on a single worskstation or server, be sure to check the global properties and runtime properties files for the following issues:

[runtime] Make sure Database connection URL is pointing to the right database.
connection.url=jdbc:mysql://localhost:3306/openmrs?autoReconnect=true

[global] Make sure that the form entry global properties are distinct.
formentry.infopath_server_url=http://localhost:8080/openmrs1
formentry.queue_dir=formentry/openmrs1/queue
formentry.queue_archive_dir=formentry/openmrs1/archive/%Y/%M

In Malawi we had an issue that caused the creation of duplicate encounters for each form entry. We realized that it was due to the fact that we had multiple instances of OpenMRS running. In our scenario, the form entry queue processor was scheduled on both instances and was looking at the same queue directory. Therefore, both tasks got to the queue at the same time and processed the incoming form entry submissions. We happened to be using the same database instance for each (one was a read-only OpenMRS instance).

4 comments:

Ben Wolfe said...

Modules could also potentially be a problem. You might be able to skip all these problems by simply setting the application_data_directory runtime property to different folders in the two different runtime property files.

Chase Yarbrough said...

If one was a read-only instance, how were they both able to create an encounter from a form?

Justin Miranda said...

By "read-only" I mean that users had only "view" privileges of the data. At this time, there's no option for setting OpenMRS to be read-only (i.e. preventing all writes to the database).

Justin Miranda said...

... well, other than creating a new database user (say openmrs_read) and granting that user SELECT privileges only.