skip to content

In JMeter's Regular Expression Extractor, what does a negative Match No. change about the variables written?

level: middleimportance: should knowfreq 49%

answer

  1. The field has three regions, not two
  2. Below zero means collect everything
  3. A count variable appears alongside numbered ones
  4. The plain reference name gets no match

basics

~10 s

A negative Match No. tells JMeter to process every occurrence. It writes refName_matchNr with the count and refName_1, refName_2 and so on for each hit, while refName itself keeps the Default Value.

solid answer

~40 s

The **Match No. (0 for Random)** field has three regions. A positive `N` takes the Nth occurrence and stops searching once it has enough. `0` picks one occurrence at random. Any **negative** value switches the extractor into collect-everything mode: it writes `refName_matchNr` holding the number of matches (which can be `0`), then `refName_1`, `refName_2`, … each built from the **Template**, plus `refName_n_gm` for the groups of match *n*. The catch that bites people is that `refName` **itself** is never assigned a match — it is left holding the **Default Value** that JMeter wrote before matching began. A plan that sets Match No. to `-1` and then references `${csrfToken}` posts the default, not a token. JMeter also removes leftover `refName_i` variables from a previous iteration once *i* exceeds the new count.

code

text · 11 lines
text
csrfToken=CSRF_NOT_FOUND
csrfToken_matchNr=3
csrfToken_1=9f2c1e7a-4b0d-4d2e-8a11-6c3b5d9e0f44
csrfToken_1_g0=name="_csrf" value="9f2c1e7a-4b0d-4d2e-8a11-6c3b5d9e0f44"
csrfToken_1_g1=9f2c1e7a-4b0d-4d2e-8a11-6c3b5d9e0f44
csrfToken_2=1a44c07e-8d31-42b6-9c50-77e2ab3f1d08
csrfToken_2_g0=name="_csrf" value="1a44c07e-8d31-42b6-9c50-77e2ab3f1d08"
csrfToken_2_g1=1a44c07e-8d31-42b6-9c50-77e2ab3f1d08
csrfToken_3=e0b81d55-2f9a-4a77-b3c1-05de6c4a9b12
csrfToken_3_g0=name="_csrf" value="e0b81d55-2f9a-4a77-b3c1-05de6c4a9b12"
csrfToken_3_g1=e0b81d55-2f9a-4a77-b3c1-05de6c4a9b12

go deeper

for a junior

Recall the three regions of the Match No. field: a positive number picks that occurrence, zero picks one at random, and a negative number collects them all.

for a middle

Explain that a negative value writes refName_matchNr plus refName_1, refName_2 and the per-match refName_n_gm groups, while the plain reference variable keeps the Default Value.

for a senior

Recognise the field left at -1 after debugging as the cause when Default Value strings appear in request bodies, and know that refName_matchNr in a dump identifies the mode.

for a principal

Decide whether iterating a match set belongs in the plan at all, and set the convention for how many occurrences a single extractor is allowed to fan out across the suite.

## Three regions of one field | Match No. | Behaviour | Variables written | |---|---|---| | `N > 0` | take the Nth occurrence, stop searching once found | `refName`, `refName_g0`…, `refName_g` | | `0` | pick one occurrence at random from all of them | `refName`, `refName_g0`…, `refName_g` | | negative | process every occurrence in the scoped text | `refName_matchNr`, `refName_1`…, `refName_n_gm` | The GUI label is *Match No. (0 for Random)*, and the component reference notes that negative values are intended for use with the **ForEach Controller**, which walks `refName_1`, `refName_2` and so on in order. ## What a negative Match No. actually writes For an extractor named `csrfToken` that found three occurrences: - `csrfToken_matchNr` — `3`. It is written even when the count is `0`, which makes it the honest signal for "did this extractor find anything?". - `csrfToken_1`, `csrfToken_2`, `csrfToken_3` — each built from the **Template**, exactly as a single-match extraction would build it. - `csrfToken_1_g0`, `csrfToken_1_g1`, … — the groups belonging to match 1, and likewise for each other match. ## What it does not write Two omissions cause almost every bug in this area: 1. **`refName` gets no match.** JMeter writes the Default Value into `refName` *before* running the pattern, and collect-everything mode never overwrites it. The component reference says so plainly: with a negative match number the reference variable is always set to the default value. 2. **`refName_gN` is not set.** The flat group variables belong to the single-match path only; with a negative Match No. the groups live under the per-match names `refName_n_gm` instead. ## Where teams get caught The usual sequence: someone sets Match No. to `-1` while debugging, because they wanted to see how many occurrences the pattern found. It works, they move on, and the plan ships with `-1` still in the field. Downstream the request references `${csrfToken}` and the server receives the literal Default Value on every iteration. Nothing in the extractor complains, because from its point of view the extraction succeeded three times. The tells are worth memorising: - a Default Value string turning up in request bodies; - `refName_matchNr` present in a variable dump, which only happens for a negative Match No.; - `refName_1` populated while `refName` is not. ## The positive case has its own subtlety With `N > 0` the extractor stops searching as soon as it has found *N* occurrences. That matters when the element is scoped over a sampler that produces sub-samples, because matching runs across the qualifying samples in turn: Match No. `3` counts the third occurrence over the whole scoped set, not the third within any single one of them. With `0` or a negative value the extractor always walks everything, because it cannot know it is finished until it has looked. That early exit is also the reason a large Match No. is not a way to "search harder" — if the pattern matches twice and you ask for occurrence 5, you get no match and the Default Value, not the last one it managed to find. ## Cleanup between iterations JMeter reads the previous `refName_matchNr` at the start of each pass and, after writing the new results, removes any `refName_i` left over from a run that found more occurrences. Without that, an iteration matching two occurrences after one matching five would leave `refName_3` through `refName_5` pointing at stale text. The count variable is removed and rewritten each time, so it always describes the current pass. ## The Boundary Extractor's version of the same field The **Boundary Extractor** carries an identical Match No. field with identical semantics for `0`, positive and negative values, and writes `refName_matchNr` and `refName_1`… the same way. The one difference is that it has no capturing groups, so nothing resembling `refName_n_gm` is ever produced by it. If you are porting an extraction from one element to the other, that is the only variable-shape change to plan for.

  • With a negative Match No., what does JMeter write when the pattern finds nothing at all?
    It still writes the count variable, as `refName_matchNr=0`, and writes no numbered variables. That makes `refName_matchNr` the reliable check for whether this extraction found anything, since the reference variable itself is simply left at the Default Value either way.
  • An iteration matched five occurrences and the next matched two. What happens to refName_3 through refName_5?
    JMeter removes them. It reads the previous `refName_matchNr` before writing the new results and deletes every numbered variable above the new count, so a later iteration cannot read stale text left by an earlier one.

saying these in an interview costs you the question

  • Says a negative Match No. means count backwards from the last occurrence
  • Expects the reference variable to hold the first of the matches
  • Confuses refName_matchNr with refName_g, the group count
  • Thinks the count variable is omitted when nothing matched
  • Believes negative values are rejected as invalid input