I’m going to post this here as a reminder to other OpenMRS developers (and myself) and to hopefully save a few hours/days of debugging. The key to getting transactions to work correctly in the webapp is to, well, tell Spring that we’re in a transaction. You can do this by simply putting an @Transactional annotation in the *Service java interface.

Without that key piece of text, the service and its methods will still work. However, they’ll work in a readonly kind of way. All data written to the database will be rolled back when the body of work has completed. This little error manifested itself recently after our reporting code-a-thon. During the event we had to create a new API service, which is only done maybe a few times a year. The service didn’t get the @Transactional tag and so therefore all database editing failed that went through the ReportService. The unit tests set up for the object passed, but that is because a unit test happens all within a single transaction — the rollback is always done after the completion of the test anyway.

I added a note to http://openmrs.org/wiki/OpenMRS_API about the requirement, but I’m sure there will be an OpenMRS developer in the future struggling with their object not saving or updating in the database and be completely baffled by it.

This is in the openmrs category tagged as , , ,

Add a comment »

I recently had a very frustrating error that I want to document here for future Googling’s sake. After a non-ideal shutdown of Tomcat and/or the jvm I was unable to start the OpenMRS webapp. Tomcat was giving this error in its log file:

Failed to read schema document 'http://www.springframework.org/schema/beans/spring-beans.xsd'

This is somewhat expected with the move from Spring 2.0 to 2.5. As of Spring Framework 2.5 the new url to use in the application context is


but even after making this change in the code and redeploying the webapp, Tomcat refused to start giving the same url (with just spring-beans.xsd).


A Spring definition file (namely applicationContext-service.xml) was being cached in Tomcat’s work directory and not being replaced on webapp deploy for some reason. I uninstalled the webapp and then deleted all files under <tomcathome>/work/localhost. Upon installing openmrs and starting Tomcat again everything started up as expected.

This is in the openmrs category tagged as , ,

1 comment »

I recently had the pleasure of setting up an ant build of OpenMRS on our new servers. After installing ant and the OpenMRS source code I kept getting a never-before-seen error when building:

No supported regular expression matcher found

I made sure I had jdk 1.6 installed. I tried upgrading to Ant 1.7 (from 1.6.5).

I ran an “ant -diagnostics”. It wasn’t showing the optional ant jars so I dropped all of the jars into the ant home lib directory. Now the jars were showing up but I was still getting the same error as before.

The solution ended up being that Ant lied to me. It was actually looking for the jars in /usr/share/java/ant (not in its reported /usr/share/ant). The puzzling thing is that Ant tells me it finds the jars when running “ant -diagnostics”.

I ended up installing the optional ant jars via yum. (or apt-get if you’re on a debian flavor) Yum didn’t have the explicit ant-optional package, so I just installed all ant-*.jar files. Voila! Successful building via ant is now possible.

This is in the openmrs category tagged as , ,

1 comment »

- 31 Oct 2007 -

I just finished poring over OpenMRS with a java memory profiler in an attempt to find where we’re leaking memory. It appears as though OpenMRS takes up more and more of the server’s memory as time progresses. However, my final conclusion is that we aren’t leaking much. I found and fixed what appeared to be memory bugs, but by and large, I think we just demand a lot of Java objects to be loaded at any given time — and Tomcat holds onto the total memory its been allocated just in case it needs it again.

A very huge find that came out of this was that we were “leaking” Tomcat sessions. In Eldoret we have about 30 data assistants right now that are filling in Infopath forms for about 8 hours a day. The average form takes about 5 minutes to fill out, so they are opening and closing Infopath fairly often. When opened, the taskpane on the side of Infopath is a mini IE browser. The first action taken by that taskpane browser is a stealing of the user’s session from their other web browser. The original session is left hanging around in Tomcat though. After 30 minutes of inactivity that session is dropped. Apparently, in our setup at least, either Tomcat or Apache has somewhere around a 250 limit on the number of sessions. With the DAs entering forms at a rapid pace, it would only take a few hours before the limit was reached — at which point Apache/Tomcat halted all traffic until some sessions were freed by timing out or Tomcat was restarted.

While trying to find the real cause of the problem, my first solution was to shorten the length of the session timeout. In <Tomcat Home>/conf/web.xml:


this obviously only lengthened the time between restarts.

The true solution came in the form of a beautiful one line fix in the formentry module: when initially loading the taskpane (before the session stealing happens) set the timeout of the current session to 10 seconds. Voila! Success! Our Eldoret server is now much more “dependable”!

Now, as far as the memory leak goes, I’d love to have some input from people who might have a better idea of what they’re doing. At times I felt as though I were just clicking randomly through the profiler looking for anything that had ‘org.openmrs…’ in the package name. If you have any pointers to give me or you have found a few memory leaks yourself, let me know!

This is in the openmrs category tagged as , ,

Add a comment »

Next Entries »