Cyclic Dependency error with bahmni modules

We are facing a cyclic dependency error (Module.error.cyclicDependencies) while starting openmrs intermittently in the current build of Bahmni. It happens once-in-a-while which is puzzling. When this issue happened, we tried to debug this issue by placing one omod at a time and restarted openmrs. We saw that it happens with providermanagement omod.

The following are some of the questions unanswered:

  1. Why does it happen intermittently and not always.
  2. When it happens, we try to restore the database to a previously working dump and openmrs starts up without any issue. How is this related to the database dump? Do we store any state in database about previous failures of openmrs.

The following are the versions of openmrs modules we use:

addresshierarchy-2.8.omod appframework-2.3.omod bacteriology-1.0-SNAPSHOT.omod bahmnicore-0.80-SNAPSHOT.omod bedmanagement-5.5-SNAPSHOT.omod calculation-1.1.omod emrapi-1.13-SNAPSHOT.omod event-2.2.1.omod htmlwidgets-1.6.4.omod idgen-4.0.omod idgen-webservices-1.1-SNAPSHOT.omod metadatamapping-1.0.2.omod metadatasharing-1.1.10.omod openmrs-atomfeed-2.5.1.omod providermanagement-2.3.omod reference-data-0.80-SNAPSHOT.omod reporting- serialization.xstream-0.2.10.omod uicommons-1.7.omod uiframework-3.4.omod uilibrary-2.0.4.omod is a fork of bahmni. Please refer to this topic for more information of why we did that:

Your help is appreciated.

The server log is available here… Please refer to the line 103. Please note that the messages about invalid omod extensions (.omod1) was renamed intentionally just to ensure that the modules are not loaded for debugging the problem.

That’s a lot of logs, with a lot of other stack trace noise. However this is the only thing that shows up about cyclic dependencies (and there’s no additional information for this).

16-02-2016 17:00:14 [ERROR] ModuleFactory - Module.error.cyclicDependencies

Unfortunately this section of code seems to be eating some information. :frowning: @bharatak, are you in a position to run OpenMRS in a debugger with a breakpoint at ModuleFactory:256 and share info about the CycleException?

This is the image while debugging the… This is just before the CycleException is thrown.

I need to see the collection of nodes also. Unfortunately the only way to “see” the cycle is by drawing the graph (or use a tool to do it).

@lluismf i think this section of code needs to be reworked a bit because of the following reasons:

  1. A module is no longer able to start if any of the modules it is aware of is not started. This should not be so. :smile:
  2. When this CycleException is thrown, all modules fail to start. Before this change, modules that have all dependencies started, would start well. And those which fail to start would display an error message with a list of dependant modules that are not started. We no longer have these error messages and hence cannot easily tell why a module failed to start.

For an example of how to reproduce a CycleException, create a dummy module that is aware of these modules:


Load this in the reference application and then stop the REST webservices module. On restarting openmrs, you should get this Module.error.cyclicDependencies where edges has this: [emrapi->dummymodule, appframework->dummymodule, appui->dummymodule]

1 Like

I assumed the dependencies were not cyclic and used Kahn’s algorithm described here:

But if cycles are allowed the algorithm is no longer valid (it’s for DAG only). Do we really want to allow cycles? This implies that if cycles are found a node in the cycle must be picked randomly. It doesn’t seem right.

Is it a good idea to add some logging in debug mode which shows the edges and collection of nodes… It might help in debugging the issue. If we are fine, I can contribute to it.

It definitely makes sense to add more logging about this, especially if it’s throwing an error.

(As a general principle, nobody every has to ask for assent before adding more debug logging to OpenMRS.)

Of course ! And if you find a graphical way to show it even better :slight_smile: