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