Jmeter View Result Tree crashes with a large payload

[gianhub16]

Expected behavior

No response

Actual behavior

No response

Steps to reproduce the problem

When a request with a long payload is sent (for example with a base64 file code), when I click on this request on the View Result Tree crashes and I am forced to terminate jmeter. Sometimes jmeter responds but only after several minutes.

I've tried with this in jmeter.properties, set jsyntaxtextarea.linewrap=false No changes

JMeter Version

5.6.2

Java Version

No response

OS Version

No response

[linvaux]

upload jmeter.log

[gianhub16]

jmeter (ok).log

[linvaux]

@gianhub16 I mean upload jmeter error log when your jmeter runs crash

[gianhub16]

This is the error that is returned when I forcibly terminate JMeter otherwise it gets stuck.

[linvaux]

Try to config JVM heap -Xms2g -Xmx4g，and threadgroup config 1 thread but , i suggest do not use GUI mode to run test， with Non-GUI

[gianhub16]

I had already made a modification on JVM Heap config. I set as you say but nothing changes.

I am interested in GUI mode because I would like to analyze request and response. The problem is only detected with the View Result Tree listener in calls with a fairly long payload.

Would it be possible to fix this issue?

[linvaux]

could you share you jmx?

[gianhub16]

You can try simply by inserting in the payload of a request a base64 code of a file about 1/2MB in size

[gianhub16]

By the way, unfortunately if you don't read the contents from the file via java string for example, you can't even paste the text of a 1MB base64. Try putting a 1MB pdf file encoded in base64 into the payload of a sample POST HTTP Request. JMeter will crash. Could you try to solve it?

[polarnik]

# Maximum size of HTML page that can be displayed; default=10 MB
# Set to 0 to disable the size check and display the whole response
#view.results.tree.max_size=10485760

# UI gets unresponsive when response contains very long lines,
# So we break lines by adding artificial line breaks
# The break is introduced somewhere in between soft_wrap_line_size..max_line_size
# We try to break on word boundaries first
#view.results.tree.max_line_size=110000
#view.results.tree.soft_wrap_line_size=100000

https://github.com/apache/jmeter/blob/master/bin/jmeter.properties#L1193C1-L1203C46

You can use the settings, for example:

view.results.tree.max_size=10000
view.results.tree.max_line_size=1000
view.results.tree.soft_wrap_line_size=1000

[polarnik]

Is your Base64 string a long-long line without any line breaks?

[gianhub16]

@polarnik

I have the same issue despite setting the parameters on jmeter.properties

Is your Base64 string a long-long line without any line breaks?

encoded-20240921162343.txt

I attach an example of a base64 string within the text file.

[polarnik]

Try putting a 1MB pdf file encoded in base64 into the payload

Try to use the tab: File

https://jmeter.apache.org/usermanual/component_reference.html#HTTP_Request

File Path: Name of the file to send. If left blank, JMeter does not send a file, if filled in, JMeter automatically sends the request as a multipart form request. When MIME Type is empty, JMeter will try to guess the MIME type of the **given file. ** If it is a POST or PUT or PATCH request and there is a single file whose 'Parameter name' attribute (below) is omitted, then the file is sent as the entire body of the request, i.e. no wrappers are added.

Fill two columns only:

• File path
• MIME but don't will the column Parameter name

As a result you will send 1 MByte, 10 MBytes, 100 MBytes witout any limits and memory overheads.

About memory overheads -- yes, you can put the long content into the JMX file, as a result the file size will be 10 MBytes for example. A file content in memory is a UTF-16 String, it will have a size ~ 40 MByte. Each thread will have a JMX content copy. Xmx1g is a HEAP Size for 1000 / 40 = 25 threads, but 100 threads will try to allocate 4g of HEAP, it will be a root cause of the OOM Error

The same script without request contents, but with the file links only, will work well without the OOM Error

[polarnik]

Thanks! I see

You use a long line.

Try to combine two peaces of advice:

• HTTP Request / File / File path without Parameter name attribute. -- It will reduce the JMX file size
  • instead of HTTP Request / Request Body
• user.properties -- it will reduce memory allocations during debugging sessions
  • view.results.tree.max_size=10000
  • view.results.tree.max_line_size=1000
  • view.results.tree.soft_wrap_line_size=1000

[polarnik]

The last hint is about java param:

-XX:+UseStringDeduplication 

Try to put it into the JVM_ARGS env variable https://github.com/apache/jmeter/blob/master/bin/jmeter.bat

All JMX file content strings are the same strings. New Java versions can reduce memory allocations for the similar strings

[polarnik]

@vlsi Can I put the option

-XX:+UseStringDeduplication

into the files:

• https://github.com/apache/jmeter/blob/master/bin/jmeter.bat
• https://github.com/apache/jmeter/blob/master/bin/jmeter.sh
• ... ?

[polarnik]

JMeter code base doesn't use the keyword String.intern() https://github.com/search?q=repo%3Aapache%2Fjmeter+intern&type=code

I will try to use it for the JMX String content. I will find a source code files via memory profiling

[gianhub16]

Any other solutions/workaround?

[FSchumacher]

@gianhub16 would you be able to build the PR for yourself and test your test plan with that fix?

[gianhub16]

,

[FSchumacher]

@vlsi Can I put the option

-XX:+UseStringDeduplication

into the files:

* https://github.com/apache/jmeter/blob/master/bin/jmeter.bat

* https://github.com/apache/jmeter/blob/master/bin/jmeter.sh

* ...
  ?

You can use that option. A better place for personalized java options would be bin/setenv.sh or bin/setenv.bat. Extra java options can be set via the env variable JVM_ARGS.

Note, that setting that option will have no effect on this problem, but may reduce memory consumption nonetheless.

[polarnik]

I can not reproduce the crash, but I have found a bottleneck.

Steps:

1. Generate a long file:

dd if=/dev/urandom of=temp_1g_file bs=1g count=1
base64 -i ./temp_1g_file -o ./temp_1g_file.txt

3. Execute a JSR-223 script with a long response data:

String fileContents = new File('~/IdeaProjects/github.com/polarnik/temp_1GB_file.txt').getText('UTF-8')
SampleResult.setResponseData(fileContents)

2 iterations 4. Start a thread group for 2 iteration, go to View Result Tree

Two configurations:

first - default

corretto-17.0.13

-Dapple.eawt.quitStrategy=CLOSE_ALL_WINDOWS -Dapple.laf.useScreenMenuBar=true -Xss256k -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant

Default settings: Darklaf - Dracula

Memory allocation: +4 GiByte after 2 iterations -1 GiByte after using GC +1 GiByte after opening a View Result Tree

Time:

• Application freeze for 2 minutes Thread:
• AWT-EventQueue-0
  • com.github.weisj.darklaf.ui.scrollpane.DarkScrollPaneUI$1.layoutContainer ()
    • com.github.weisj.darklaf.delegate.ScrollLayoutManagerDelegate.layoutContainer ()
      • javax.swing.ScrollPaneLayout.layoutContainer ()

In two minutes we will see an active View Result Tree

second - look and feel = System

corretto-17.0.13

-Dapple.eawt.quitStrategy=CLOSE_ALL_WINDOWS -Dapple.laf.useScreenMenuBar=true -Xss256k -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8 -Duser.country=US -Duser.language=en -Duser.variant

Custom theme: System

Memory allocation — the same: +4 GiByte after 2 iterations -1 GiByte after using GC +1 GiByte after opening a View Result Tree

Time:

• 0 time

[polarnik]

Result 1

The theme Darklaf - Dracula is root cause of slow response time + 2 minutes for the View Result Tree

• AWT-EventQueue-0
  • com.github.weisj.darklaf.ui.scrollpane.DarkScrollPaneUI$1.layoutContainer ()
    • com.github.weisj.darklaf.delegate.ScrollLayoutManagerDelegate.layoutContainer ()
      • javax.swing.ScrollPaneLayout.layoutContainer ()

The workaround — use the theme System

[polarnik]

View Result Tree has a memory leak:

• clicking by each item allocates additional memory for the response, and the GC can not deallocate it

The test: Apache JMeter, 2 items with big responses (1 GiByte) in a View Result Tree component

Steps:

• click on the first item
• call a java GC
• click on the second item
• call a java GC

Actual result:

• +1 GiByte allocation
• nothing
• +1 GiByte allocation
• nothing

Expected result:

• +1 GiByte allocation
• nothing
• +1 GiByte allocation
• -1 GiByte allocation (a component View Tree is not working with the item 1 right now)

View Result Tree items allocate memory for the total response size with ignoring the option view.results.tree.max_size=10485760

• the response body uses a limit 10 485 760 bytes, but the View Result Tree allocates a full response size (1 GiByte)

The test: Apache JMeter, 2 items with big responses (1 GiByte) in a View Result Tree component

Steps:

• click on the first item
• click on the second item

Actual result:

• +1 GiByte allocation
• +1 GiByte allocation

Expected result:

• +10 485 760 bytes allocation
• +10 485 760 bytes allocation

[polarnik]

View Result Tree has a memory leak for the last selected item

Test 1, don't select anything

Steps:

• Start the test with 5 iteration
• Don't open a component View Result Tree
• Click the JMeter GUI button Clear All
• java GC

Actual Result:

• • 6 GiByte memory allocation
• 0 memory usage

Test 2, select an item in a View Result Tree

Steps:

• Start the test with 5 iteration
• Click by any item of the View Result Tree
• Click the JMeter GUI button Clear All
• java GC

Actual Result:

• • 6 GiByte memory allocation
• 3 GiByte memory usage

The First GC Root for the first big object:

• responseData in org.apache.jmeter.samplers.SampleResult#2
  • sampleResult in org.apache.jmeter.visualizers.RenderAsText#1
    • resultsRender in org.apache.jmeter.visualizers.ViewResultsFullVisualizer#1
      • [0] in java.lang.Object[]#20205 : 10 items
        • elementData in java.util.ArrayList#543 : 1 element
          • component in javax.swing.JViewport#2
            • viewport in javax.swing.JScrollPane#2
              • mainPanel in org.apache.jmeter.gui.MainFrame#1 [GC root - JNI global] : Thread Group.jmx (/Users/Viacheslav.Smirnov/IdeaProjects/github.com/polarnik/Thread Group.jmx) - Apache JMeter (6.0.0-SNAPSHOT 6d39ac6)

The second GC Root for the second big object:

• value in java.lang.String#71821 : eq2KPpD78ptL+uQIgIUJ8hnJSLKoQLOAyvhOJSBR+HI3Lw8TAq9I7NhGc54Edsl7CkA/52h85T7xmjJzvy2NfJVYZ2dv7aONCerjwZTLX+UBebZOZWou5XnY9lbuFe23tnk4n3t90Fp3/hkvsgpl7jdgZO8/pA2e...
  • responseDataAsString in org.apache.jmeter.samplers.SampleResult#2
    • sampleResult in org.apache.jmeter.visualizers.RenderAsText#1
      • resultsRender in org.apache.jmeter.visualizers.ViewResultsFullVisualizer#1
        • [0] in java.lang.Object[]#20205 : 10 items
          • elementData in java.util.ArrayList#543 : 1 element
            • component in javax.swing.JViewport#2
              • viewport in javax.swing.JScrollPane#2
                • mainPanel in org.apache.jmeter.gui.MainFrame#1 [GC root - JNI global] : Thread Group.jmx (/Users/Viacheslav.Smirnov/IdeaProjects/github.com/polarnik/Thread Group.jmx) - Apache JMeter (6.0.0-SNAPSHOT 6d39ac6)