Why does a JMeter XML result file carry every response body when no listener was configured to save one?
answer
- Look above the listeners, not at them
- A Test Plan checkbox, not a property file
- It overrides every listener's save configuration
- One output format gains no response data
basics
~10 sFunctional Test Mode was ticked on the Test Plan element. That single checkbox writes TestPlan.functional_mode and forces Response Data and Sampler Data into every result file, overriding each listener's own save configuration.
solid answer
~40 sThe Test Plan element carries a checkbox labelled *Functional Test Mode (i.e. save Response Data and Sampler Data)*, stored as `TestPlan.functional_mode`. It is a plan-level override, not a listener setting: `SampleSaveConfiguration.saveResponseData()` returns true if the listener asked for it **or** if functional mode is on, and the same holds for sampler data. So every listener writing an XML result file starts carrying full response bodies even though nobody touched a listener's Configuration button. The manual is blunt about the cost — the file grows huge quickly and JMeter's performance suffers — and the GUI prints "Selecting Functional Test Mode may adversely affect performance" beneath the box. Two details are worth remembering: the option does not affect CSV result files, which cannot store that information, and it also switches off the renaming of sub-results.
code
xml · 5 lines<TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Checkout plan">
<boolProp name="TestPlan.functional_mode">true</boolProp>
<boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
<boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
</TestPlan>go deeper
Know that the Test Plan element has a Functional Test Mode checkbox and that it makes JMeter save response data. You are not expected to have debugged an oversized result file yet.
Explain the override. The plan-level flag is ORed with each listener's own save configuration, so checking every listener will not reveal the cause; the property is TestPlan.functional_mode in the .jmx.
Recognise the symptom from the artefacts: an enormous XML result file, responseData on every sample, no listener configured to save it, and lower injector throughput than the same plan gave before.
Make it unrepeatable. Decide whether a plan carrying functional mode may be committed at all, and put the check somewhere a human does not have to remember it before a long run is scheduled.
## The one checkbox that overrides every listener JMeter's Test Plan element has three checkboxes. One of them is *Functional Test Mode (i.e. save Response Data and Sampler Data)*, persisted as the boolean property `TestPlan.functional_mode`. The manual describes it as making JMeter "record the data returned from the server for each sample", and warns in the same paragraph that "the file will grow huge quickly, and JMeter's performance will suffer". What makes it a diagnosis question rather than a trivia question is where the override lives. Each listener has a **Configuration** button that decides which fields it saves. Functional mode does not change those settings — it short-circuits them. In `SampleSaveConfiguration`: - `saveResponseData(res)` returns true when the listener asked for response data, **or** functional mode is on, or the sample failed and save-on-error is set; - `saveSamplerData(res)` follows the same shape. So an engineer can open every listener, confirm that none of them is set to save response data, and still be looking at result files full of bodies. The cause is one node higher, on the Test Plan itself. ## What it actually changes - **Response Data** and **Sampler Data** are written to all result files that can hold them. - **Sub-result renaming is disabled.** `SampleResult.isRenameSampleLabel()` returns false when functional mode is on, so sub-samples keep their own labels instead of being renamed by position. The property `subresults.disable_renaming` does the same thing independently. - **CSV result files gain no response data.** The reference states the option "does not affect CSV result files, which cannot currently store such information", and the CSV writer has no notion of response data at all. The `saveResponseData(res)` / `saveSamplerData(res)` overrides are read only by the XML converters (`SampleResultConverter`, `HTTPResultConverter`), so a team writing CSV JTLs pays neither the size nor the performance cost — the manual is explicit that "if you are not recording the data to file, this option makes no difference". One thing does still reach their file: with renaming off, `HTTPAbstractImpl.configureSampleLabel` labels every HTTP sample with its URL instead of the sampler's name. ## How the symptom usually arrives The common route is a plan that someone debugged in the GUI. Ticking functional mode is genuinely the right move for a small correctness run — the manual recommends it exactly for that, "if you are doing a small run to ensure that JMeter is configured correctly, and that your server is returning the expected results". The box then gets committed with the plan, and the next non-GUI load run inherits it. The signature is distinctive: 1. The result file is orders of magnitude larger than the sample count would suggest. 2. Every `<sample>` element carries a `<responseData>` child, and often `<samplerData>` too. 3. No listener's saved configuration explains it. 4. Throughput on the injector is lower than the same plan produced last week, for no change in the system under test. ## How to check and how to fix The fastest check does not need the GUI. Open the `.jmx` and read the Test Plan element's `TestPlan.functional_mode` property; it is a plain boolean. Set it to false, or clear the checkbox on the Test Plan panel, and rerun. If a subset of samplers genuinely needs full detail, the manual's own advice is to keep functional mode off and "add a Listener to it, and configure the fields as required" — a scoped listener rather than a plan-wide switch. ## Why it is a family question This is a Test Plan-level setting, and the Test Plan is not a member of any Add-menu family: it is the root that carries the settings the whole tree inherits. Candidates who reason family by family look at listeners, because listeners are the family that writes result files. The answer is that one element above the families can override what a whole family does — which is exactly why "which element owns this behaviour?" is worth asking about a plan you did not write.
- The team writes CSV result files. Does Functional Test Mode still bloat them?No, and it costs them nothing either. The reference states the option does not affect CSV result files, which cannot store that information, and in the code the functional-mode override is consulted only by the XML converters — `CSVSaveService` has no notion of response data at all. What does survive is the renaming switch — every HTTP sample is labelled with its URL rather than the element name, and sub-results, which CSV does write, keep their own labels.
- Besides saved fields, what else does Functional Test Mode change?It disables sub-result renaming. `SampleResult.isRenameSampleLabel()` returns false when the mode is on, so sub-samples keep their own labels rather than being renamed by position. The `subresults.disable_renaming` property has the same effect independently of the mode.
- You need full responses for two samplers only. What do you do instead?Leave Functional Test Mode off and attach a listener scoped to those samplers, using its Configuration button to save response and sampler data. That keeps the cost proportional to the two samplers rather than applying it to every sample in the run.
saying these in an interview costs you the question
- Blaming a listener's Configuration button for a bloated result file
- Assuming Functional Test Mode only changes the GUI view
- Believing CSV result files gain response bodies too
- Leaving Functional Test Mode ticked for a load run
- Looking for a jmeter.properties key instead of a Test Plan property