Bug 64658 - System modal splash screen is "blocking" the user
Summary: System modal splash screen is "blocking" the user
Status: RESOLVED FIXED
Alias: None
Product: JMeter
Classification: Unclassified
Component: Main (show other bugs)
Version: 5.3
Hardware: PC All
: P2 normal (vote)
Target Milestone: JMETER_5.3.1
Assignee: JMeter issues mailing list
URL:
Keywords:
: 62179 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-08-10 08:15 UTC by Marc Stern
Modified: 2020-09-06 08:51 UTC (History)
1 user (show)



Attachments
Loaded plug-ins (10.39 KB, image/png)
2020-08-10 13:48 UTC, Marc Stern
Details
Log (13.30 KB, text/plain)
2020-08-11 07:08 UTC, Marc Stern
Details
Full log including jmx loading (156.69 KB, application/x-zip-compressed)
2020-08-11 07:16 UTC, Marc Stern
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marc Stern 2020-08-10 08:15:26 UTC
When loading JMeter, the splash screen (at least under Windows) is system modal, meaning it's on top of everything running on the desktop.
The splash screen is stays in the middle of the screen (no way to move it), on top of all other windows, thus partially hiding most applications windows.
When loading a big test file, the splash screen stays on my (pretty recent and powerful laptop) sometimes up to 30 s. So I cannot work at all for 30 s, which is very frustrating.
Why is the splash screen system modal and not application modal? The latter sounds the most logical to me and is aligned with good practices.
Thanks
Comment 1 Felix Schumacher 2020-08-10 09:53:30 UTC
A normal startup time with splash screen should be around a second or two, not thirty seconds.

Do you have any third party plugins installed?
Are there any log/error messages in the log file jmeter.log?
Would you be able to take a few threaddumps of the JVM while starting JMeter?

To your last question: patches are welcome :)
Comment 2 Marc Stern 2020-08-10 11:10:51 UTC
As I said, the delay may increase a lot when you load a test at start-up (-t mytestfile.jmx).

For the patch, although it's probably trivial (a constant to change in the method call), I unfortunately don't have the Java skills to do it :-(
Comment 3 Felix Schumacher 2020-08-10 13:36:53 UTC
Can you please answer the questions? I think the answers might be helpful (to help you).

I don't think, that JMeter sets explicitly the splash screen to be system modal and my rudimentary search on google told me, that Java doesn't support a system modal dialog. Perhaps you are annoyed by the always on top dialog, which is a slightly different (but probably also annoying) thing.
Comment 4 Marc Stern 2020-08-10 13:48:21 UTC
Created attachment 37388 [details]
Loaded plug-ins
Comment 5 Marc Stern 2020-08-10 13:51:34 UTC
You're right, it's an "always on top dialog" - bad wording.

Starting JMete alone takes 15 s; adding a big jmx file can addd 15 or 30 s.
I attached a screenshot of my plug-ins.
Nothing in jmeter.log.
Taking threaddumps is out of my expertise :-(
Comment 6 Felix Schumacher 2020-08-10 14:10:39 UTC
If you are using a current version of OpenJDK (or a commercially licensed Oracle JDK), you can enable the flight recorder and look into the state of the JVM afterwards.

You could add the following line to your bin/setenv.bat (or bin/setenv.sh under linux) to enable the flight recorder and save the events in a file named recording.jfr

JVM_ARGS="-XX:StartFlightRecording=disk=true,dumponexit=true,filename=recording.jfr,maxsize=1024m,maxage=1d,settings=profile,path-to-gc-roots=true"

(Note I have tried this under linux, only)

The recording can be analysed with the tool Mission Control (which can be downloaded from the AdoptOpenJDK and other places).

If you are not afraid to send the recording data to me, I could take a look into it.

Another trick you could try is to look at the network connections JMeter is trying to open on startup (it shouldn't open any on it's own, but the plugins might do so) with a windows system monitoring tool you like.
Comment 7 Felix Schumacher 2020-08-10 16:06:27 UTC
Hi Marc,

to debug your problems hopefully a bit easier, I have added debug messages at the point in the startup sequence, that happens when the splash screen is displayed.

To enable the debug logs, you have to add an entry to bin/log4j2.xml

<Logger name="org.apache.jmeter.JMeter" level="debug" />

I placed it directly under the entry for name="org.apache.jmeter.junit".

On the next start up, you should see the following lines in the jmeter.log file:

2020-08-10 17:59:06,697 DEBUG o.a.j.JMeter: Apply HiDPI on fonts
2020-08-10 17:59:06,697 DEBUG o.a.j.JMeter: Configure PluginManager
2020-08-10 17:59:06,698 INFO o.a.j.JMeter: Loaded icon properties from org/apache/jmeter/images/icon.properties
2020-08-10 17:59:06,720 DEBUG o.a.j.JMeter: Setup tree
2020-08-10 17:59:07,040 DEBUG o.a.j.JMeter: populate command map
2020-08-10 17:59:07,553 DEBUG o.a.j.JMeter: init instance
2020-08-10 17:59:07,553 DEBUG o.a.j.JMeter: constructing main frame

commit 44c0c7ee1a18b86528adf07607839614166d60f6
AuthorDate: Mon Aug 10 17:59:56 2020 +0200

    Log status on start up, when splash screen is displayed
    
    Be more verbose on the init phase, when the startup splash screen
    is being displayed. This can hopefully be used to pinpoint problems
    on startup more easily.
    
    Bugzilla Id: 64658
---
 src/core/src/main/java/org/apache/jmeter/JMeter.java | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
Comment 8 Felix Schumacher 2020-08-10 16:34:16 UTC
Note: The logging will only work with the next nightly or builds from trunk. (See https://jmeter.apache.org/nightly.html)
Comment 9 Marc Stern 2020-08-11 07:08:02 UTC
Created attachment 37389 [details]
Log

This log corresponds to a display of the splash screen of about 33 s
Comment 10 Marc Stern 2020-08-11 07:16:25 UTC
Created attachment 37390 [details]
Full log including jmx loading

I enabled debug for everything.
We see here that it's the loading of the jmx that takes most of the time (more than normal because we are in debug).
Comment 11 Marc Stern 2020-08-11 07:21:18 UTC
Felix, I'd love if you could speed-up the load of my project, obviously.
Anyway, I think the splash screen shouldn't stay on top of other windows - that's very intrusive. Maybe an option?
Comment 12 Vladimir Sitnikov 2020-08-11 07:43:52 UTC
Marc,
1) Splash screen disappears just when the application is ready. Making it disappear earlier won't enable you work with the application earlier

2) The log you provide does include java.lang.OutOfMemoryError: Java heap space
So I would suggest either increase -Xmx or collect a heap dump and analyze it for the heap consumption

3) Could you share the jmx file so we can replicate the issue?
Comment 13 Marc Stern 2020-08-11 08:45:47 UTC
1) Splash screen disappears just when the application is ready. Making it
disappear earlier won't enable you work with the application earlier
No, but at least I would be able to work on other Windows ...

2) The log you provide does include java.lang.OutOfMemoryError: Java heap space
So I would suggest either increase -Xmx or collect a heap dump and analyze it
for the heap consumption
That's just because the debug mode uses too much memeory for a big project

3) Could you share the jmx file so we can replicate the issue?
If needed, but I have the same problem with all projects.
Maybe I wasn't clear:
If you have a big project, it takes a long time to load it. I understand and I accept that. The only problem is that I cannot work on my PC when it's loading the project. The point is not to optimize the project load time (even if I would be happy to gain a few seconds), but simply to not block my screen with an image forbidding me to work. I would like to choose which window is on top myself and I don't see why JMeter should take such an initiative.
Comment 14 Felix Schumacher 2020-08-11 10:03:01 UTC
Adding a command line parameter to disable the splash screen would probably be an option to solve one of your problems.

But I think it would even be better to make the import faster.

There are a lot of "clean cookies" messages from the debug log (thanks for providing it) and I wonder, if we "enable/reset" the added elements too often on load.

Can you give us more information on your used test plan? It seems to be rather big and I would like to test it locally, to get a better understanding, where we should optimize the loading sequence.
Comment 15 Marc Stern 2020-08-11 10:07:39 UTC
A command line parameter to disable the splash screen would be perfect
Comment 16 Felix Schumacher 2020-08-16 11:16:36 UTC
Disable splash screen per CLI option: 
https://github.com/apache/jmeter/pull/610
Comment 17 Marc Stern 2020-08-17 06:39:32 UTC
Great, Thanks.
As soon as a JAR will be available, I'll test it.
Comment 18 Felix Schumacher 2020-08-17 08:46:33 UTC
In my experiments with the big test plan (that Marc has sent me privately), it is a really bad idea to enable the undo feature. It seems to be enabled while loading and really hurts performance wise.

The test plan is built with quite a lot of different thread groups that can be enabled to test different things. The thread groups themselves are build from loops, samplers (JSR223, Beanshell, HTTP), config elements, but are not too big themselves. There are a few global config elements like a dns cache manager with static host entries (build from variables). And last but not least it contains module fragments, that are referenced inside the thread groups.
Comment 19 Marc Stern 2020-08-17 09:07:21 UTC
I suppressed the "undo" and it makes indeed a huge difference!
Thanks for spotting the problem.
Comment 20 Vladimir Sitnikov 2020-08-20 18:41:59 UTC
Marc, I've merged https://github.com/apache/jmeter/pull/614 which makes the splash-screen JMeter-modal rather than system modal.

So it should no longer block other apps even in the case JMeter takes long to launch.

You could find the build here: https://ci-builds.apache.org/job/JMeter/job/JMeter-trunk/43/ (or you can build from source by downloading git tree and running ./gradlew runGui)
Comment 21 Marc Stern 2020-08-21 09:27:03 UTC
It's perfect, thanks
Comment 22 Felix Schumacher 2020-09-06 08:51:11 UTC
*** Bug 62179 has been marked as a duplicate of this bug. ***