[BUG] Mirth Connect Admin locks up on 4.2 with channel source JS Reader when scrolling through the code

[MattWeig]

Describe the bug
Launch mirth admin, go to channels, select channel that is a JS Reader source, scroll in the code for 10-15 seconds. Admin locks up and must be closed via task manager. Mirth version 4.2, able to reproduce any time.

Expected behavior
Mirth Admin to not lock up

Actual behavior
Mirth Admin locks up

Screenshots

Environment (please complete the following information):

Workaround(s)
Are there one or more workarounds for this issue currently?

Additional context
Add any other context about the problem here.

[MattWeig]

Workaround:
Use the MCAL as normal
Launch MC as normal
Close MCAL
Log in to MC

[jonbartels]

Same workaround #4333

Symptoms are similar in that the MC Client freezes but it happens in a different area of the application.

[jonbartels]

I reproduced the problem on MC 4.3.0 and MCAL 1.3.1 on Windows in AWS Workspaces.

Thread dump from the MC Client process is attached.
5765.dump.txt

[jonbartels]

Ok so this is wild.

Try this process as a workaround:

1. Open MCAL
2. Set "Show Console" to "Yes"
3. Launch MC
4. Scroll around in a JS transformer a lot
5. The local console will spam errors but MC Client will not lock

Longer test case:

1. Open MCAL
2. Set "Show Console" to "Yes"
3. Launch MC
4. Scroll around in a JS transformer a lot
5. The local console will spam errors but MC Client will not lock
6. Close the console window.
7. Scroll around in a JS transformer a lot
8. MC Client will still not lock
9. Keep this MC Client window open
10. Go back to MCAL
11. Set "Show Console" to "No"
12. Launch a second instance of MC Client
13. Scroll around in a JS transformer a lot
14. The second instance of MC Client will lock

Having these two instances of the client running should show any differences between the two.

This failure mode seems to be consistent with "AWT-EventQueue-0" #15 prio=6 os_prio=0 tid=0x0000000019bc1800 nid=0x1654 runnable [0x000000001b41e000] from my earlier thread dump. MC Client is trying to write something but can't.

I got on a video call with @tonygermano and he saw it happen live. What it seems like is that MC Client is looking for stderr or stdout and doesn't have it. Something with how MCAL is launching MC Client isn't letting it write to that output stream.

In Linux or MacOS I would run lsof and see what streams the process has open. I do not know how to do that in Windows.

[ab-20-m]

It sounds like stdout and stderr are getting redirected from the child process even when "Show Console" is set to "No". If that is the case, the buffers likely aren't being read. The buffers will fill and eventually the child writes will block, at least on Windows.

[ChristopherSchultz]

If @ab-20-m is right, the child process can hang if the parent process isn't processing the child process's stdout and stderr streams. Odd that the event queue is writing to a file. If we could (officially) look at the source for MCAL we could see hwo they are launching the child process.

It's starting to sound like the process-launch code isn't quite right.

[tonygermano]

@pladesma @lmillergithub I'm pretty sure this is a duplicate of #4333 . Unless RS-9061 was created to handle the ClassCastException rather than the application hang. It's really two different issues.

[jonbartels]

#5789 is another instance of this problem