skip to content

A JMeter CSV Data Set Config feeds 200 threads the same few rows. What went wrong?

level: seniorimportance: should knowfreq 58%

answer

  1. Two threads, one file, one pointer?
  2. A dropdown decides who shares
  3. Aliases, not partitions
  4. Check the field below Stop thread

basics

~20 s

Sharing mode is set to Current thread, which opens a separate reader per thread, each starting at line one. Only All threads, the default, gives one shared file pointer so no two threads take the same line.

solid answer

~40 s

This is the classic `Sharing mode` misreading. JMeter keeps one open reader per **alias** in its `FileServer`, and `CSV Data Set Config` builds that alias from the `Filename` plus a suffix from Sharing mode: nothing for `All threads`, the thread group's identity for `Current thread group`, the thread's identity for `Current thread`. `Current thread` therefore opens the file 200 times rather than splitting it 200 ways — and **every reader starts at line 1**, so all 200 threads march down the same opening rows in lockstep. The 10,000-row file looks perfectly healthy afterwards because its later rows were never touched. The fix is the default, `All threads`: reads go through one synchronized pointer, so each line is handed to exactly one thread per pass.

code

xml · 4 lines
xml
<stringProp name="shareMode">shareMode.all</stringProp>
<stringProp name="shareMode">shareMode.group</stringProp>
<stringProp name="shareMode">shareMode.thread</stringProp>
<stringProp name="shareMode">logins-pool-A</stringProp>

go deeper

for a junior

Recall that Sharing mode exists and that All threads is the default. Know that it decides who shares one position in the file, not how the file is divided up.

for a middle

Explain the alias mechanism: the filename plus a suffix per mode, one reader per distinct alias, every reader starting at line 1. That is why Current thread duplicates rather than partitions.

for a senior

Diagnose it from the symptom. A handful of accounts taking all the traffic while the file looks clean points at Sharing mode, not at the data. Know that the default serialises reads so no two threads take one line.

for a principal

Own how data pools are shared across plans and thread groups: which groups draw from a common pool, which need their own, and how that intent is expressed so a reviewer can see it in the JMX.

## Sharing mode keys the file, it does not partition it All of JMeter's in-test file reading goes through one `FileServer`, which keeps a single open reader per **alias**. `CSV Data Set Config` builds that alias from the `Filename` string plus a suffix chosen by **Sharing mode**: | Sharing mode | Alias used | Readers opened for 200 threads in 2 thread groups | |---|---|---| | `All threads` (the default) | the filename alone | 1 | | `Current thread group` | filename plus the group's identity | 2 | | `Current thread` | filename plus the thread's identity | 200 | | free-typed identifier | filename plus your text | one per distinct text | Every distinct alias gets its own reader, and **every reader starts at line 1**. That is the whole defect: `Current thread` does not slice the file 200 ways, it opens the same file 200 times. ## Why the symptom looks like a data problem - On the first iteration all 200 threads read row 1; on the second, all 200 read row 2. - Rows past the highest iteration count are never touched, so opening the file shows 10,000 perfectly good distinct credentials and no duplicates. - With `Current thread group` the same thing happens once per group, which is why a plan looks correct on a single-group smoke test and duplicates as soon as a second group is added. - Server-side, this shows up as a small set of accounts taking all the traffic — easy to misread as an application problem rather than a plan problem. ## What All threads guarantees, and what it does not Reads go through a synchronized method on the shared `FileServer`, so two threads cannot be handed the same line: each call advances the one pointer by one row. What the default does **not** promise is *which* thread gets *which* row. Lines go out in whatever order threads happen to reach their iteration start, and that order varies between iterations and between runs, so the mapping from thread to credential is not reproducible. ## The fourth option the dropdown does not list The `Sharing mode` combo is editable. Type anything that is not one of the three preset values — say `logins-pool-A` — and every `CSV Data Set Config` carrying that exact text shares one reader for that file. This is the only way to share a pool between *some* thread groups: with four groups, two can carry `logins-pool-A` and two can carry `logins-pool-B`, giving two independent walks through the same file. ## The suffix is an identity, not a name For `Current thread group` and `Current thread` the suffix is the runtime identity of the group or thread object, not its display name. Two things follow: - The aliases are **not stable between runs**, so you cannot use them to pin a particular group to a particular part of the file. - The element is cloned per thread, but cloning does not open a reader — only a new alias does. Two hundred clones under `All threads` still share one entry, which is exactly why the default behaves as it does. If you want a stable, human-readable grouping, the free-typed identifier is the only sharing key you choose yourself rather than one JMeter derives. ## If you genuinely need per-thread rows 1. Split the 10,000 rows into one file per thread up front. 2. Give `Filename` a per-thread name — JMeter's manual builds one from the thread number for exactly this case. 3. Set `Sharing mode` to `Current thread`, so each thread reserves its own file rather than its own pointer into a shared one. 4. Remember that recycling and end-of-file behaviour now apply per thread, so one thread can exhaust its file while others are still working.

  • Under the default All threads mode, can you predict which thread receives which row?
    No. Reads are serialised, so each line goes to exactly one thread per pass, but lines go out in whatever order threads reach their iteration start. That order varies between iterations and between runs, so the thread-to-row mapping is not reproducible.
  • How would you give each JMeter thread a genuinely private set of credential rows?
    Split the file up front into one file per thread, build the Filename from the thread number as JMeter's manual does, and set Sharing mode to Current thread. Each thread then reserves its own file rather than its own pointer into a shared one.
  • How do you share one file between exactly two of four thread groups?
    Type your own identifier into the Sharing mode combo, which is editable. Elements carrying the same text share a reader, so two groups can use one identifier and the other two another, giving two independent walks through the file.

One ticket dispenser in a bakery versus giving every customer their own fresh roll of tickets. Share the dispenser and no two people hold the same number; hand out a roll each and all of them are holding ticket 1.

saying these in an interview costs you the question

  • Says Current thread gives each thread its own distinct rows.
  • Assumes the default Sharing mode isolates each thread group.
  • Blames duplicate rows in the file rather than checking Sharing mode.
  • Thinks Recycle on EOF is what makes threads repeat the same rows.
  • Believes threads read the file in a fixed, reproducible order.