When going to cohort builder, unable to access it getting the following error:
An Internal Error has Occurred
java.lang.IllegalArgumentException
Comparison method violates its general contract
Possibly related, this error was found within a day after using metadata sharing to bring order sets to the server using Order Extension Module.
That same error was received by one user ordering one of the order sets that was imported using metadata sharing.
The cohort builder error also showed up on another server that is was synced with using Sync module.
Possibly related, a few servers within a day of this had issues with submitting forms where the form would say “You must log in again before the form can be submitted” even though the user was logged in. This particular issue appeared to be solved by restarting the server.
Server details:
Server version: Apache Tomcat/7.0.62
Server built: May 7 2015 17:14:55 UTC
Server number: 7.0.62.0
OS Name: Linux
OS Version: 3.13.0-101-generic
Architecture: amd64
JVM Version: 1.7.0_80-b15
JVM Vendor: Oracle Corporation
java -version
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
Our best hypotheses center around java versions (which we can’t figure out how they would have changed) or the metadata share of the order set (though the interaction is non obvious). Furthermore, the fundamental error may be related to the following issue outside OpenMRS https://issues.apache.org/jira/browse/SPARK-13850
The link above that @toddandersonpih shared is not the issue, but I found it and shared it because it seemed to indicate that this error can manifest when there is a fatal error inside of the sort method (i.e. this may have nothing to do with a sort method violating it’s general contract, but rather that might be the error that gets thrown inadvertently when some other fatal condition occurs).
Our best guess right now is that there is a bad hibernate error (lazy loading probably) happening when fetching concept names (this is something that seems to happen a lot), and this is what is causing the error. That would also explain why a metadata import caused this to start happening. So I think we should pursue this line of investigation and see if we can find something amiss with those concepts that would cause the system to fail when loading them.
Incidentally, and not entirely related (but related in that it will be hard to fix this for Rwanda in the master branch) - I notice that we increased the minimum OpenMRS version requirement of cohort builder to the 2.x line a while back. What would we have done this? Given that this is a legacy module and we are actively trying to work on a newer alternative, making this module no longer compatible with legacy implementations running older versions of core seems like the wrong approach. @dkayiwa / @raff / @wyclif / @darius, thoughts on this? Is this something that we can reverse?
Update: @jberchmas found a drug with a NULL name that was brought over from the metadata share. When this was given a name, the cohort builder error disappeared.
@mseaton assuming you are referring to the reporting compatibility module, a number of classes were moved from the core platform to this module hence requiring a lot of work to have the same module running on both platform 2.x and lower versions. This was coupled with the fact this module is eventually getting deprecated (not much more active development going into it besides a few bug fixes).
Basing on that background, the easiest fix was to have a 1.x branch for those running on platform 1.x
@dkayiwa - thanks, that does make sense. I remember this now.
I think I was confused because I noticed that the latest 1.x-compatible version in the module repository was 1.5.8 and put there almost 5 years ago The head of the 1.x branch in github is at 1.5.12-SNAPSHOT. So it seems that we are not doing a very good job of ensuring that the module repository is updated when we do a new release. Luckily, the design of the new add-on-index is such that this will be a concern of the past very soon
The head of the 1.x branch in github is at 1.5.12-SNAPSHOT. So it seems that we are not doing a very good job of ensuring that the module repository is updated when we do a new release. Luckily, the design of the new add-on-index is such that this will be a concern of the past very soon