In JMeter's JSON Extractor, what has to match when you extract two values at once?
answer
- Four fields, all of them lists
- The separator is a semicolon
- Lengths are compared before extraction runs
- One field is optional only for one value
basics
~10 sThe counts must match. JMeter splits Names of created variables, JSON Path expressions and Default Values on semicolons and rejects the element when those three lists come out different lengths.
solid answer
~50 sThe JSON Extractor is a **multi-value** element: **Names of created variables**, **JSON Path expressions**, **Default Values** and **Match No. (0 for Random)** are each a semicolon-separated list, and JMeter splits all four on `;`. Before it extracts anything it checks that names, expressions and defaults have the **same number of entries**; if they do not, it throws and logs *Mismatch between number of variables, json expressions and default values*. The practical consequence is that **Default Values stops being optional** the moment you extract more than one value: with two names you must supply two defaults, even if one of them is empty. Match No. is treated more leniently — leave it blank and every expression gets `0`, meaning random selection. The alternative to one multi-value element is several single-value elements, which is easier to read and easier to disable one at a time.
code
xml · 7 lines<JSONPostProcessor guiclass="JSONPostProcessorGui" testclass="JSONPostProcessor" testname="Capture confirmation" enabled="true">
<stringProp name="JSONPostProcessor.referenceNames">orderId;orderTotal</stringProp>
<stringProp name="JSONPostProcessor.jsonPathExprs">$.order.id;$.order.totals.grand</stringProp>
<stringProp name="JSONPostProcessor.match_numbers">1;1</stringProp>
<stringProp name="JSONPostProcessor.defaultValues">NO_ORDER_ID;NO_TOTAL</stringProp>
<boolProp name="JSONPostProcessor.compute_concat">false</boolProp>
</JSONPostProcessor>go deeper
Recall that this element can capture several values at once and that all of its value fields are lists sharing one separator character.
Explain the length check across names, expressions and defaults, and why a field the documentation calls optional stops being optional past one value.
Show how you debug a mismatch you cannot see: count the entries the split actually produces rather than the separators visible in the box.
Decide as a matter of plan convention whether captures are packed into one element or split across several, and hold the plan to that choice.
Assumed version: Apache JMeter 6.0.0. ## Four fields, four lists The JSON Extractor was built to pull several values out of one body. Each of its four value fields is a **semicolon-separated list**, and the element splits every one of them on `;` before it does any work: - **Names of created variables** — `JSONPostProcessor.referenceNames` - **JSON Path expressions** — `JSONPostProcessor.jsonPathExprs` - **Default Values** — `JSONPostProcessor.defaultValues` - **Match No. (0 for Random)** — `JSONPostProcessor.match_numbers` Entry *i* of each list belongs to entry *i* of the others. Names and expressions are trimmed, so spaces around the semicolons are harmless. ## The check that has to pass Before extracting anything, the element compares the lengths of **names**, **expressions** and **defaults**. Any disagreement and it throws, logging both a developer hint — *check you use separator ';' if you have many values* — and the user-facing message *Mismatch between number of variables, json expressions and default values*. That check is the reason Default Values is documented as optional but behaves as mandatory: | Names | Expressions | Default Values | Outcome | |---|---|---|---| | `orderId` | one expression | *(blank)* | Fine — a blank field splits to one empty entry | | `orderId;total` | two expressions | *(blank)* | **Mismatch** — one default against two names | | `orderId;total` | two expressions | `NO_ID;` | Fine — two entries, the second empty | | `orderId;total` | two expressions | `NO_ID;NO_TOTAL` | Fine | ## Why a trailing semicolon behaves differently per field Default Values is split keeping trailing empty entries, so `NO_ID;` yields **two** defaults, the second an empty string. Names and expressions are split the ordinary way, so a trailing semicolon on those lines is simply dropped: `orderId;` gives **one** name, not two. A stray semicolon at the end of the names line therefore does not create a phantom variable — it silently shortens the list and then trips the mismatch check, which is a far more confusing symptom than it sounds when you are staring at a field that visibly contains two things. ## Match No. is validated separately Match No. is *not* part of the length check. It is read as its own semicolon-separated list and sized to match the defaults: 1. **Blank** — every expression gets `0`, which means random selection among that expression's matches. 2. **`1;1`** — first match for both expressions, the setting you almost always want for a confirmation body. 3. **`1;-1`** — different behaviour per expression, which is legal and occasionally useful. The entries must parse as integers; a typo like `1;one` fails at parse time rather than at extract time. ## Compute concatenation var The fifth control, **Compute concatenation var (suffix _ALL)**, is a single checkbox rather than a list — it applies to the whole element, is off by default, and only does anything for expressions whose Match No. is negative. ## One element or several? The multi-value form is compact but it is not free of downsides: - Every list must stay aligned by hand; adding a field means editing four boxes, and forgetting one gives you the mismatch error rather than a helpful diff. - You cannot disable a single capture; the element is all or nothing. - The element name in the tree can only describe one of the captures, so the plan reads worse. - Folding expressions together does **not** save the body from being parsed again per expression, so the compactness buys readability trade-offs rather than work avoided. Against that, one element is one place to set *Apply to*, and one thing to move if the sampler moves. For two related values out of the same confirmation body the multi-value form is reasonable. For five unrelated captures, separate elements almost always read better. ## The sibling element that has no lists at all JMeter's **JSON JMESPath Extractor** is deliberately single-valued: one expression, one variable name, one default, one Match No., no semicolon lists and no `_ALL` checkbox. If you find yourself fighting list alignment, that element sidesteps the whole problem by refusing to do more than one thing at a time.
- The names field visibly holds two names but JMeter reports a mismatch. What would you check first?A trailing semicolon on the names or expressions line. Those two fields are split discarding trailing empties, so `orderId;total;` still yields two names while `orderId;` yields one. Compare the entry counts the split actually produces rather than the commas you can see, and confirm Default Values carries the same count.
- Is Default Values required or optional on this element?Documented optional, effectively required beyond one value. A blank field splits to a single empty entry, which matches a single name but not two. With two names you must supply two entries — `NO_ID;` counts as two, the second empty — or the length check fails before any extraction happens.
- What does leaving Match No. blank do when the element has three expressions?All three get `0`, which means each expression independently picks one of its matches at random. It is not the same as `1;1;1`. With single-match bodies the two behave identically, which is why the mistake survives review and then shows up as an intermittent failure once a body carries two matches.
saying these in an interview costs you the question
- Thinks a single default value is reused for every expression
- Separates the names with commas rather than semicolons
- Calls Default Values optional when several values are extracted
- Reads a blank match number field as meaning the first match
- Adds a trailing separator and expects an extra empty entry everywhere