TRUNK-6409: Initializer module should not re-run initialization on each node by IamMujuziMoses · Pull Request #307 · mekomsolutions/openmrs-module-initializer

IamMujuziMoses · 2025-11-27T15:44:38Z

Issue I worked on

see https://issues.openmrs.org/browse/TRUNK-6409

Checklist: I completed these to help reviewers :)

My IDE is configured to follow the code style of this project.

No? Unsure? -> configure your IDE, format the code and add the changes with git add . && git commit --amend
I have added tests to cover my changes. (If you refactored
existing code that was well tested you do not have to add tests)

No? -> write tests and add them to this commit git add . && git commit --amend
I ran mvn clean package right before creating this pull request and
added all formatting changes to my commit.

No? -> execute above command
All new and existing tests passed.

No? -> figure out why and add the fix to your commit. It is your responsibility to make sure your code works.
My pull request is based on the latest changes of the master branch.

No? Unsure? -> execute command git pull --rebase upstream master

IamMujuziMoses · 2025-11-27T15:49:07Z

@rkorytkowski @dkayiwa @ibacher could you please review this PR, your feedback will be appreciated.

IamMujuziMoses · 2025-11-27T15:51:09Z

api/src/main/java/org/openmrs/module/initializer/InitializerActivator.java

 		InitializerMessageSource messageSource = getInitializerMessageSource();
 		Context.getMessageSourceService().setActiveMessageSource(messageSource);

+		boolean isPrimary = Boolean.parseBoolean(getPropertyValue(PROPS_PRIMARY_STARTUP, "false"));


@rkorytkowski do you mean something like this where the system property primary.startup is added to thee runtime.properties

@IamMujuziMoses TRUNK-6409 is about persisting checksums in a dedicated table in DB instead of in filesystem and then adding a check to run import only on one replica at a time. It can be achieved similar to how liquibase does it i.e. have a mutex like flag in db that is checked before running an import and having a node that starts the import to hold it until it's done before any other node can do it. This way we don't have to set any node as primary. The drawback is that each node will be doing a check if checksums changed and comparing to DB persisted values, but that should be quick and can be further optimised if needed. I think it's simplifies deployments. You don't have to keep 2 different deployments and remember to deploy in sequence. I'll update the issue description.

@rkorytkowski Thanks for the review, this makes sense, I'll rework the solution to use a DB-based lock.

rkorytkowski · 2026-02-11T09:41:12Z

api/src/main/java/org/openmrs/module/initializer/InitializerActivator.java

 		InitializerMessageSource messageSource = getInitializerMessageSource();
 		Context.getMessageSourceService().setActiveMessageSource(messageSource);

+		boolean isPrimary = Boolean.parseBoolean(getPropertyValue(PROPS_PRIMARY_STARTUP, "false"));


@IamMujuziMoses TRUNK-6409 is about persisting checksums in a dedicated table in DB instead of in filesystem and then adding a check to run import only on one replica at a time. It can be achieved similar to how liquibase does it i.e. have a mutex like flag in db that is checked before running an import and having a node that starts the import to hold it until it's done before any other node can do it. This way we don't have to set any node as primary. The drawback is that each node will be doing a check if checksums changed and comparing to DB persisted values, but that should be quick and can be further optimised if needed. I think it's simplifies deployments. You don't have to keep 2 different deployments and remember to deploy in sequence. I'll update the issue description.

rkorytkowski

Also please note that the module already persist checksums for files in the filesystem. We need to put those checksums in DB so they are available for all nodes and not lost with filesystem failure.

ibacher · 2026-02-12T18:11:13Z

An important additional consideration here is that it's possible to disable Iniz's run on start-up and run it manually. People doing something like this need to have an easy API to correctly obtain whatever mutex we're using.

IamMujuziMoses · 2026-02-20T12:19:34Z

@rkorytkowski @ibacher could you please review this, did you mean something like this?

rkorytkowski

Thanks! Going in the good direction. Still a few tweaks needed.

rkorytkowski · 2026-02-20T17:14:12Z

api/src/main/java/org/openmrs/module/initializer/api/InitializerServiceImpl.java

+	@Override
+	public String getOrCreateNodeId() {
+		AdministrationService admin = Context.getAdministrationService();
+		String nodeId = admin.getGlobalProperty(GP_NODE_ID);


Am I missing something or each node uses the same GP? Is it just for debugging purposes? I would just get rid of node id entirely.

We could use e.g. hostname for locked_by.

rkorytkowski · 2026-02-20T17:16:27Z

api/src/main/java/org/openmrs/module/initializer/api/entities/InitializerLock.java

+	private Date lockedAt;
+
+	@Column(name = "locked_by")
+	private String lockedBy;


It would be good to have lock_until set to e.g. 15 minutes so that it is automatically freed if not released due to failure.

rkorytkowski · 2026-02-20T17:18:48Z

api/src/main/java/org/openmrs/module/initializer/api/entities/InitializerLock.java

+	private Integer id;
+
+	@Column(name = "locked", nullable = false)
+	private Boolean locked;


Rather than having the locked field, I would just have a String primary key with a name of the lock e.g. 'initializer'. I would insert when taking the lock and delete the row when releasing.

Having locks with different names would mean that if someone runs initializer in their own module, it can use a different lock name and thus run initialisation regardless of the default initialization done by the core module.

rkorytkowski · 2026-02-20T17:21:18Z

api/src/main/java/org/openmrs/module/initializer/InitializerActivator.java

+				// Check if config changed
+				if (!getInitializerService().isConfigChanged()) {
+					log.info("No config changes... skipping initializer");
+					return;


It shouldn't be just skipping. It should be waiting until lock is released.

okay, I get it now, thanks for the review

I mean it should wait and then skip. The wait is so that we don't start up another instance before initialization is done.

rkorytkowski · 2026-02-20T17:23:08Z

api/src/main/java/org/openmrs/module/initializer/api/HibernateInitializerDAO.java

+				+ "SET locked = true, lockedAt = current_timestamp, lockedBy = :node "
+		        + "WHERE id = 1 AND (locked = false OR lockedAt < :expiryTime)";
+
+		Date expiryTime = new Date(now - LOCK_TIMEOUT);


I see you have expiryTime. I would still put it in the table so that if we need we can have different locks with different expiry times.

rkorytkowski · 2026-02-20T17:27:22Z

api/src/main/java/org/openmrs/module/initializer/api/InitializerServiceImpl.java

+				String checksum = DigestUtils.sha256Hex(fis);
+				map.put(rel.toString(), checksum);
+			} catch (Exception e) {
+				map.put(f.getName(), "ERROR");


Isn't the initalizer module computing the checksums elsewhere and persisting them in the filesystem? We need to remove that old behavior.

Yes I think it's this, should I remove it completely?

Yes, we need to remove it, but also if checkums are there, we should put them in DB so that we don't re-run everything when upgrading the module.

…ch node

IamMujuziMoses · 2026-03-02T21:45:12Z

@rkorytkowski could you please review these updates

rkorytkowski · 2026-03-06T16:58:57Z

@IamMujuziMoses thanks, I'll go through your code and do testing on Monday.

rkorytkowski · 2026-03-09T11:46:29Z

api/src/main/java/org/openmrs/module/initializer/InitializerActivator.java

+
+				// Run Initializer
+				log.info("OpenMRS config loading process started...");
 				getInitializerService().loadUnsafe(true, throwError);


My understanding is that with your changes if only a single checksum is different, then all files are being loaded again instead of just the one that changed... It's not correct. Only that single file should run. I'll fix that issue.

rkorytkowski · 2026-03-09T12:02:04Z

api/src/main/java/org/openmrs/module/initializer/api/InitializerServiceImpl.java

+
+				try (InputStream is = Files.newInputStream(path)) {
+					Path rel = base.relativize(path);
+					String checksum = DigestUtils.sha256Hex(is);


You changed the checksum from md5Hex to sha256Hex... which is probably fine, but you don't seem to handle migration from file stored checksums to db checksums. I'll address that as well.

rkorytkowski · 2026-03-09T12:14:29Z

api/src/main/java/org/openmrs/module/initializer/InitializerActivator.java

 				getInitializerService().loadUnsafe(true, throwError);
+
+				// Save new checksums
+				getInitializerService().updateChecksums();


We should not updateChecksums all at once... It's possible that some files get imported and checksums should be updated and some fail... I'll address that as well.

rkorytkowski · 2026-03-09T12:15:35Z

Thanks @IamMujuziMoses! I've left a few review comments. Let me address them as I need to get it done today.

rkorytkowski · 2026-03-10T12:22:49Z

PR with fixes: #319

This one (#307) can be closed.

IamMujuziMoses commented Nov 27, 2025

View reviewed changes

rkorytkowski suggested changes Feb 11, 2026

View reviewed changes

IamMujuziMoses force-pushed the TRUNK-6409 branch from e113bf6 to eaa59ff Compare February 20, 2026 12:07

rkorytkowski suggested changes Feb 20, 2026

View reviewed changes

IamMujuziMoses added 2 commits March 2, 2026 16:28

TRUNK-6409: Initializer module should not re-run initialization on ea…

6cc66c7

…ch node

TRUNK-6409: Initializer module should not re-run initialization on ea…

b916fd5

…ch node

IamMujuziMoses force-pushed the TRUNK-6409 branch from eb55043 to 2f03a29 Compare March 2, 2026 16:07

IamMujuziMoses requested a review from rkorytkowski March 2, 2026 16:10

TRUNK-6409: Initializer module should not re-run initialization on ea…

ff6848d

…ch node

IamMujuziMoses force-pushed the TRUNK-6409 branch from 2f03a29 to ff6848d Compare March 2, 2026 16:27

rkorytkowski reviewed Mar 9, 2026

View reviewed changes

rkorytkowski mentioned this pull request Mar 10, 2026

TRUNK-6409 Initializer module should not re-run initialisation on each node #319

Open

Conversation

IamMujuziMoses commented Nov 27, 2025

Issue I worked on

Checklist: I completed these to help reviewers :)

Uh oh!

IamMujuziMoses commented Nov 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rkorytkowski Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rkorytkowski Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rkorytkowski left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ibacher commented Feb 12, 2026

Uh oh!

IamMujuziMoses commented Feb 20, 2026

Uh oh!

rkorytkowski left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

IamMujuziMoses commented Mar 2, 2026

Uh oh!

rkorytkowski commented Mar 6, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rkorytkowski commented Mar 9, 2026

Uh oh!

rkorytkowski commented Mar 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rkorytkowski Feb 11, 2026 •

edited

Loading

rkorytkowski Feb 11, 2026 •

edited

Loading

rkorytkowski left a comment •

edited

Loading

rkorytkowski commented Mar 10, 2026 •

edited

Loading