Platform 1.10.2 Blocker: Updating mappings is very slow

Hello all–

We’ve run into a blocker with OpenMRS 1.10.2. We’ve got our Mirebalais modules to automatically update to new point releases of OpenMRS, so when 1.10.2 was released (yesterday?) some of our Mirebalais modules picked it up.

There’s a test in our Mirebalais Metadata module that tests installing all our metadata–this test is slow, and usually takes 10-15 minutes to run, but after updating from 1.10.1 to 1.10.2 it runs for 90+ minutes without finishing. I see that there were classloader changes in 1.10.2, as well as the fixes for the Hibernate 3/4 issue that we have been discussing recently, so I’m guessing something around these changes is the culprit.

In particular, it is the “updating mappings” section of a metadata import (ImportPackageTask: 90-105) that is particularly slow. For instance, for one rather large metadata package, this block took about 1 minute to execute when running against 1.10.1, but 10 minutes to execute when running against 1.10.2. Later, it is during the “updating mappings” block while importing another package that the test hangs entirely.

So there seems to be some sort of significant performance hit between 1.10.1 to 1.10.2. It’s possible that the issue is just in very specific cases or in tests, and not a “real” problem, but until this is determined this is a blocker for us to upgrade to 1.10.2. And, also, in my opinion, this is a blocker to upgrading 30+ modules to rely on 1.10.2 in order to resolve this issue:

Thanks! I will let you know if I discover anything else, but I’m not planning on putting too much time into it at this moment as we are looking to get a release of our system out the door.

Mark

2 Likes

Thanks Mark for the quick report! I will look into that.

As an additional piece of info, if you want to reproduce, you can check out the mirebalais metadata module, change the pom to use OpenMRS 1.10.2, and do a maven clean install. It should hang during the MirbalaisMetadataActivatorComponentTest.

Good news! I had to look into this more today because I realized that we need some features in the 1.10.2 release and believe I narrowed down the problem and it isn’t a blocker.

The commit that introduced the problem was a one-line change to the pom that upgraded the version of H2 we are using from 1.2.135 to 1.4.183. This 1.4.183 was a beta release and had a blocker bug: “In version 1.4.183, indexes were not used if the table contains columns with a default value generated by a sequence. This includes tables with identity and auto-increment columns. This bug was introduced by supporting “rownum” in views and derived tables.”

So since we only use H2 for testing, this bug should only manifest itself in tests.

I’ve downgraded to the most recent stable release of H2 and am testing now.

3 Likes