Mirth Connect freezes when editing JavaScript (in a transformer)

[rbeckman-nextgen]

In the past week I've been having a lot of problems with Mirth freezing whenever I tried to edit JavaScript in it. The workaround of writing/editing JavaScript in a code editor and then - pasting it into Mirth worked to a certain extent, except when the action of pasting also caused Mirth to freeze. Monitoring Mirth's output in its Java console showed the following error that did not immediately cause the crash but seems to be related to it: Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: org.mozilla.javascript.ast.WhileLoop cannot be cast to org.mozilla.javascript.ast.DoLoop at org.fife.rsta.ac.js.ast.parser.JavaScriptAstParser.processDoNode(JavaScriptAstParser.java:412) at org.fife.rsta.ac.js.ast.parser.JavaScriptAstParser.iterateNode(JavaScriptAstParser.java:160) at org.fife.rsta.ac.js.ast.parser.JavaScriptAstParser.addCodeBlock(JavaScriptAstParser.java:103) at org.fife.rsta.ac.js.ast.parser.JavaScriptAstParser.convertAstNodeToCodeBlock(JavaScriptAstParser.java:61) at org.fife.rsta.ac.js.SourceCompletionProvider.iterateAstRoot(SourceCompletionProvider.java:423) at org.fife.rsta.ac.js.SourceCompletionProvider.getCompletionsAt(SourceCompletionProvider.java:172) at com.mirth.connect.client.ui.components.rsta.ac.js.MirthSourceCompletionProvider.getCompletionsAt(MirthSourceCompletionProvider.java:104) at org.fife.ui.autocomplete.LanguageAwareCompletionProvider.getCompletionsAt(LanguageAwareCompletionProvider.java:140) at org.fife.ui.autocomplete.LanguageAwareCompletionProvider.getToolTipText(LanguageAwareCompletionProvider.java:415) at org.fife.ui.rtextarea.RTextArea.getToolTipText(RTextArea.java:829) at org.fife.ui.rsyntaxtextarea.RSyntaxTextArea.getToolTipTextImpl(RSyntaxTextArea.java:1760) at org.fife.ui.rsyntaxtextarea.RSyntaxTextArea.getToolTipText(RSyntaxTextArea.java:1736) at javax.swing.ToolTipManager$insideTimerAction.actionPerformed(Unknown Source) at javax.swing.Timer.fireActionPerformed(Unknown Source) at javax.swing.Timer$DoPostEvent.run(Unknown Source) at java.awt.event.InvocationEvent.dispatch(Unknown Source) at java.awt.EventQueue.dispatchEventImpl(Unknown Source) at java.awt.EventQueue.access$500(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.awt.EventQueue$3.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source) at java.awt.EventQueue.dispatchEvent(Unknown Source) at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.pumpEvents(Unknown Source) at java.awt.EventDispatchThread.run(Unknown Source)

I was able to reproduce this behavior on a fresh VM with a similar setup (Ubuntu + OpenJDK 11 + Mirth 3.8). However, it only happened when I was connecting to the Mirth server from a Windows client. When I connected from a Linux client, there were no freezes and no error messages in the Java console. That may explain the reason why such bug may have been missed by Mirth employees, they don't use Windows workstations and the problem seems to be affecting only the Windows clients.

Upon further investigation, it seemed that this issue is happening only when using Mirth Connect Administrator Launcher application. Starting Mirth Connect from a JNLP file seems to cause no problems. Mirth Connect Administrator Launcher uses its own bundled JRE, so the client Java version is not relevant. Unfortunately, JNLP technology is being obsoleted by Java and on our network access to Mirth server's administration page is blocked as "insecure" (because of its expired certificate).

A possible solution to the problem (which I am testing right now) is to set the option "Use Legacy DH Settings" in Mirth Connect Administrator Launcher to "Yes". That stops the Java console error seen without this setting, and editing JavaScript in Mirth has not crashed on me yet. But I need more time to test that.

Imported Issue. Original Details: Jira Issue Key: MIRTH-4458 Reporter: aitougan Created: 2019-09-19T14:59:59.000-0700

[kirbykn2]

I am seeing the same issue. Did "Use Legacy DH Settings" resolve the issue for you?

[dmkellyj1]

I am running into this issue as well. Almost every time I am editing javascript in the transformer, Mirth administrator locks up and can only be closed by killing the task in task manager. "Use Legacy DH Settings" did not resolve the issue for me. Has there been any follow up on this?

[bhushanjborole]

I am running into this issue as well. I am using Mirth Connect 3.8.1, any follow up on this?

[DFranqueira]

Hi! Having the same exact problem in version 3.9.0. Any news on this issue? Thanks

[elavy-harris]

I'm having the same issue with version 4.0.0. Changing "Use Legacy DH Settings" had no effect, but opening the JNLP directly avoids the freeze.

[rbiderma]

It has been happening to me also if I'm working in a javascript that has while(cond){} loop and I was able to consistently replicate it (open a script with a while loop, leave it open for a few seconds and the MC freezes). It didn't seem to happen on do{}while(cond) loops and in my case I am able to switch to using those. Surprisingly, when I tried replicating it right after OS restart it was not happening, but after a while ( :-) ) it starts again. I'm using Windows 10 for the client (java version "1.8.0_341", Java(TM) SE Runtime Environment (build 1.8.0_341-b10), Java HotSpot(TM) 64-Bit Server VM (build 25.341-b10, mixed mode)) and the server is on Linux, mirth 3.10.1. "Use Legacy DH Settings" didn't seem to have any effect for me either.

[DFranqueira]

@elavy-harris is right, I started opening all my mirth instances directly from the JNLP and never had this issue anymore. It's a shame tho. I liked using the mirth Administrator launcher

[kirbykn2]

Close the administrator launcher after you launch MC.

On Thu, Aug 4, 2022 at 11:24 AM DFranqueira @.***> wrote:

Can confirm this, I started opening all my mirth instances directly from the JNLP and never had this issue anymore. It's a shame tho. I liked using the mirth Administrator launcher

— Reply to this email directly, view it on GitHub https://github.com/nextgenhealthcare/connect/issues/4333#issuecomment-1205406114, or unsubscribe https://github.com/notifications/unsubscribe-auth/APRXWD5TZKVUBLEVTRMUIMTVXPOBBANCNFSM4M6IVZWA . You are receiving this because you commented.Message ID: @.***>

-- Best,

Kirby Knight | 231.735.4650 | @.***

[tiskinty]

@kirbykn2 Can confirm, checking the "Close this window after launching" or manually closing launcher seems to be the best workaround I've found. (Mirth Connect 3.9.1, Administrator Launcher 1.2, Windows 11)

[tonygermano]

Until MCAL is made open source, I can't tell exactly what it is doing, but if you start a process with java.lang.Runtime.exec(), the resulting Process has its std i/o piped and available to the parent process via InputStreams and OutputStreams. These are buffered streams and only allow so much to be written to them before they block waiting on the other end to read the data, which MCAL appears to not be doing. Turning on the java console gives that data a place to go.

You can see how it's properly handled here: https://github.com/nextgenhealthcare/connect-examples/blob/master/Code%20Templates/Execute%20Runtime%20Command/Execute%20Runtime%20Command.js

The code template fires up two additional threads, one to read stdout and one to read stderr, so that the process does not get stuck while it's running. Accumulating all of the input into one giant string works for the code template, but is probably not the best thing to do for a long running process like the mc client, but at least it shows how the streams need to be handled.

Alternatively, the process could be created with ProcessBuilder, which would allow MCAL to set the client to inherit its own i/o redirects (probably should be the default) or redirect them to a file, which would actually be a nice feature of MCAL to allow easy capture of client exceptions.

Starting with java 9 (#5759), there is a static field ProcessBuilder.Redirect.DISCARD, which writes output to /dev/null in a platform independent way so that the parent process can send the child's output nowhere, if it chooses.

[tonygermano]

Additional investigative work was done on this topic by @jonbartels on ticket #5765, including verifying that enabling the option to show the java console is another viable workaround.

[jonbartels]

https://github.com/nextgenhealthcare/connect/discussions/5789 is another instance of this problem