O3 without demo data

Development
1

Is there a way to setup O3 without the referenceapplication-demo content? O3 Reference Application - Build Backend: Plan summary - OpenMRS Bamboo includes all demo data in the openmrs_config dir. It would be nice to have a docker image variant that includes only the necessary files to start. Actually, IMO it should be the default one.

I’m asking because I want to run a startup performance test and the initial setup takes ~30 minutes and demo data is not needed there at all.

2

@raff if you meant demo patient data rather than demo metadata (the initial metadata found in the openmrs_config directory), you can disable automatic demo patient data generation on first startup by setting the appropriate global property. Using the Iniz globalproperties domain, whose config files are also located under openmrs_config, the configuration (somewhere here) might look like this:

<config>
    <globalProperties>
        <globalProperty>
            <property>referencedemodata.createDemoPatientsOnNextStartup</property>
            <value>0</value>
        </globalProperty>
    </globalProperties>
</config>
3

For demo patients, we moved that to content packages: openmrs-content-referenceapplication-demo/configuration/backend_configuration/globalproperties/globalproperties-core_demo.xml at main · openmrs/openmrs-content-referenceapplication-demo · GitHub

But i noticed of late that even when i set that to zero, the startup time is still alot and so far what i have noticed is that the openconceptlab module takes more than 50% of the startup time while importing concepts and mappings. This was while using the SDK. Surprisingly, using docker seems to take way much less time to startup, even for a fresh setup.

4

@paynejd FYI. Reminds me also that I don’t think we haven’t finalized my concern about updating the patient demo data.

5

I meant without both demo metadata and data.

I went ahead and created a distro-no-demo.properties without content.referenceapplication-demo and omod.referencedemodata. See O3-5256

6

I’m not sure regarding the metadata there as extraneous is the right thing to do. Most of the metadata there is the type of stuff that a full installation would need, which is part of the reason it’s part of the default image, because we’re trying to create something that’s closer to a useable application. The demo data generation, of course, isn’t essential to that.

7

I see. The ‘demo’ in name makes it look extraneous.

Maybe we could identify if there is something in there that is truly demo and move the rest to the main content package.

There’s one ocl package that is particularly large and takes a lot of time to load… openmrs_DiagnosesStarterKit_v4_autoexpand-4.2025-07-16_045128.zip It’s ~42 MBs after unzipping. Also the demo content from the ocl dir is producing lots of errors during the initial load.

8

This explains why the openconceptlab module takes the biggest chunk of the initial startup time. It takes way more time than that needed to generate demo data by the referencedemodata module.

I thought we had cleared these. How do they look like?

9

e.g.

ERROR - ImportTask$1.run(105) |2025-12-09T11:30:52,780| Failed to import mapping org.openmrs.module.openconceptlab.client.OclMapping@2db33d[externalId=136432ABBBBBBBBBBBBBBBBBBBBBBBBBBBBB]

org.openmrs.module.openconceptlab.importer.ImportException: Cannot save mapping /orgs/CIEL/sources/CIEL/mappings/9001/

	at org.openmrs.module.openconceptlab.importer.Saver.saveMapping(Saver.java:533) ~[openconceptlab.jar:?]

	at org.openmrs.module.openconceptlab.importer.ImportTask$1.run(ImportTask.java:96) ~[openconceptlab.jar:?]

	at org.openmrs.api.context.Daemon.lambda$runInDaemonThreadInternal$5(Daemon.java:489) ~[openmrs-api-2.8.2-SNAPSHOT.jar:?]

	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) ~[?:?]

	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317) ~[?:?]

	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]

	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]

	at java.base/java.lang.Thread.run(Thread.java:1583) [?:?]

Caused by: org.openmrs.module.openconceptlab.importer.SavingException: Cannot create mapping from concept with URL /orgs/CIEL/sources/CIEL/concepts/1599/, because the concept has not been imported

	at org.openmrs.module.openconceptlab.importer.Saver.saveMapping(Saver.java:368) ~[openconceptlab.jar:?]

	... 7 more
10

In the logs, do you see any deadlocks causing transaction rollbacks?

11

Yes, scrolling up I see lots of:

	at jdk.proxy9/jdk.proxy9.$Proxy259.updateConceptWithoutValidation(Unknown Source) ~[?:?]

	at org.openmrs.module.openconceptlab.importer.Saver.saveMapping(Saver.java:412) ~[openconceptlab.jar:?]

	... 7 more

Caused by: java.sql.BatchUpdateException: (conn=58) Deadlock found when trying to get lock; try restarting transaction

	at org.mariadb.jdbc.export.ExceptionFactory.createBatchUpdate(ExceptionFactory.java:221) ~[mariadb-java-client-3.5.4.jar:?]

It’s easy to reproduce. You just need to run from https://github.com/openmrs/openmrs-distro-referenceapplication:

docker compose down -v

docker compose up
12

Yes those deadlocks come from the ThreadPoolExecutor in this class: openmrs-module-openconceptlab/api/src/main/java/org/openmrs/module/openconceptlab/importer/Importer.java at master · openmrs/openmrs-module-openconceptlab · GitHub

And they fail randomly.

@raff do you have any objection to NOT running ocl imports in parallel threads?

13

It may be much slower, but it’s worth trying. I would try to fix the transaction issue.

14

I’m not sure we get much benefit from parallelism here…