jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Sitnikov <>
Subject Re: GUI Mode : OOM Protection for View Results Tree or View Results in Table
Date Thu, 02 Feb 2017 20:44:43 GMT
>Can you clarify your question if it's a real one.

Well, that's a real question.
It is a long time since I launched a load test, and I can't remember if
faced "UI stuck" error ever.

I would admit I've never used non-GUI mode, and GUI was just fine for me
(of course I had to disable things like "view results").

Philippe>Did you see the last thread "High CPU utilization in
JMeter 3.x with HttpClient 4 leads to freeze" ?

I think I missed that.
A quick glance (e.g. ) shows
that we have a logging problem.

That is  org.apache.jmeter.gui.LoggerPanel.processEvent might fill UI event
queue, thus rendering UI unresponsive.

We might want to have some throttling there, or circular buffering, or
lazy-loading (e.g. logging to a file and refreshing it to the UI from time
to time).

In any way, the number of threads itself has nothing to do with UI
responsiveness provided there is enough Xmx (remember we did discuss
"please specify new Xmx value and click restart" dialog?) and there is
enough CPU power (in case of CPU starvation the load test makes no sense at

Philippe>blocks Load test mode

You are right. It is much better to have application level error that
explains what goes wrong rather than fail with some obscure error at

However I would like to explore if we can have a way out without stopping
the show.

When captain opens the thread dump above, he would find some obvious things:
1) Logging fills the UI queue. The simplest workaround would be to disable
log panel updates after N messages.
2) Statistics posts UI events as well (SummaryReport.add). Can we have some
debounce there, so the UI gets refreshed once a second at most?

Well, the above do not look like a quick win, however I think those can be
fixed without complicating the codebase too much.

Does it make sense to spawn a couple of new mail threads regarding those


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message