How many iterations does one thread run in JMeter's Open Model Thread Group?

seniorshould knowfreq 33%

answer

An arrival and an iteration coincide
The group installs its own controller
Count the fields the GUI offers
Nothing on the element caps threads
Concurrency is an outcome, not an input

basics

~20 s

Exactly one. Each scheduled arrival gets its own thread, that thread walks the group's children once and exits, and the group's controller marks itself done after the first iteration. There is no loop-count field to change this.

solid answer

~50 s

The Open Model Thread Group installs its own main controller, and that controller sets itself done once the first iteration has been served — the source comment says every thread performs just one iteration. So an arrival, a thread and an iteration are the same event here. The element's GUI reflects that: the only load fields are Schedule and Random Seed, with no Number of Threads, Ramp-up or Loop Count. Threads are created on demand from a cached pool as arrivals come due, and the group does not cap how many exist at once, so the live thread count is a consequence of the schedule you wrote rather than something you set. Two practical effects: per-thread state does not survive from one arrival to the next, and anything you would normally repeat with a loop has to be expressed either as more arrivals or with a controller inside the iteration.

The Open Model Thread Group installs its own main controller, and that controller sets itself done once the first iteration has been served — the source comment says every thread performs just one iteration. So an arrival, a thread and an iteration are the same event here. The element's GUI reflects that: the only load fields are **Schedule** and **Random Seed**, with no Number of Threads, Ramp-up or Loop Count. Threads are created on demand from a cached pool as arrivals come due, and the group does not cap how many exist at once, so the live thread count is a consequence of the schedule you wrote rather than something you set. Two practical effects: per-thread state does not survive from one arrival to the next, and anything you would normally repeat with a loop has to be expressed either as more arrivals or with a controller inside the iteration.

code

xml · 3 lines

xml

<OpenModelThreadGroup guiclass="OpenModelThreadGroupGui" testclass="OpenModelThreadGroup" testname="Arrivals" enabled="true">
  <stringProp name="OpenModelThreadGroup.schedule">rate(50/sec) random_arrivals(10 min) pause(2 min) random_arrivals(10 min) pause(5 min)</stringProp>
</OpenModelThreadGroup>

go deeper

for a junior

Remember that each arrival in this thread group is one thread running the group's children once, and that the element has no loop count or thread count to set.

for a middle

Explain that the group replaces the usual loop controller with one that marks itself done after the first iteration, so arrival, thread and iteration are the same event.

for a senior

Show you can reason about the consequences at run time: an iteration that grows longer raises overlap without any field changing, and the tail of such a run is what a trailing pause protects.

for a principal

Own the reviewability angle: a plan whose load lives in one schedule string and whose concurrency is an outcome needs its iteration duration watched, because nothing in the plan file records it.

One arrival, one thread, one iteration

In JMeter's Open Model Thread Group these three words describe the same event. The group's starter task walks the schedule, and for each scheduled arrival instant it builds a JMeterThread over a cloned copy of the group's subtree and submits it to a thread pool. The group also installs its own main controller in place of the loop controller other thread groups use, and that controller marks itself done as soon as one iteration has been served — the comment in the source is blunt: for now, every thread performs just one iteration.

The element's GUI matches. Its component reference lists three properties only — Name, Schedule and Random Seed — so there is no Number of Threads, no Ramp-up Period and no Loop Count to reach for.

Where the thread count comes from

Nothing on the element sets it. Threads are created on demand as arrivals fall due, taken from a cached pool so that a thread which has finished can be reused for a later arrival, and the group's own documentation states that the maximum number of threads is not limited. The number alive at any instant is therefore a consequence of the schedule you wrote and of how long an iteration takes to run — an outcome you observe, not an input you supply.

That is also why the doctrine about this element matters: it is a core component with a cached pool, but it is not a multiplexed runtime. Every concurrently running user still holds its own platform thread while it runs.

What follows for a plan

Per-thread state does not carry over. Each arrival is a new iteration in a fresh thread context, so anything a plan would normally accumulate across iterations of one user is not available here.
There is nothing to loop. A step you want repeated has to be either a second arrival — more schedule — or a controller nested inside the single iteration.
An iteration that runs long raises concurrency, silently. Adding steps to the iteration does not change the arrival schedule, so the same schedule now keeps more threads alive at once with no field anywhere recording that.
The tail is interrupted. Because the group terminates threads when the schedule ends, a long iteration is also the thing most likely to be cut off, which is what a trailing pause(...) is for.

Reading it in the .jmx

The element is written under the alias OpenModelThreadGroup, with OpenModelThreadGroupGui as its GUI class, and it carries its schedule under the property name OpenModelThreadGroup.schedule (with the seed alongside it as OpenModelThreadGroup.random_seed). A reviewer scanning a plan can tell an open-model group from any other thread group by the absence of a thread count in the XML — the load lives entirely in the schedule string.

In the logs

Two strings help when you are watching a run:

the starter thread renames itself open-model-thread-starter-<group name>-<index>, so you can find it in a thread dump;
the group logs Starting OpenModelThreadGroup#<index> with schedule <text> at start, which is the fastest way to confirm which profile a headless run actually used after property substitution.

The common wrong answers

"It loops until the schedule ends" — no; the schedule keeps producing new arrivals, and each of those is a new thread doing one iteration.
"Set Loop Count to control it" — there is no such field on this element.
"The pool size caps concurrency" — the pool is unbounded; it caches idle threads for reuse rather than limiting live ones.

## One arrival, one thread, one iteration In JMeter's Open Model Thread Group these three words describe the same event. The group's starter task walks the schedule, and for each scheduled arrival instant it builds a `JMeterThread` over a cloned copy of the group's subtree and submits it to a thread pool. The group also installs its own main controller in place of the loop controller other thread groups use, and that controller marks itself done as soon as one iteration has been served — the comment in the source is blunt: for now, every thread performs just one iteration. The element's GUI matches. Its component reference lists three properties only — Name, Schedule and Random Seed — so there is no Number of Threads, no Ramp-up Period and no Loop Count to reach for. ## Where the thread count comes from Nothing on the element sets it. Threads are created on demand as arrivals fall due, taken from a cached pool so that a thread which has finished can be reused for a later arrival, and the group's own documentation states that the maximum number of threads is not limited. The number alive at any instant is therefore a consequence of the schedule you wrote and of how long an iteration takes to run — an outcome you observe, not an input you supply. That is also why the doctrine about this element matters: it is a core component with a cached pool, but it is not a multiplexed runtime. Every concurrently running user still holds its own platform thread while it runs. ## What follows for a plan 1. **Per-thread state does not carry over.** Each arrival is a new iteration in a fresh thread context, so anything a plan would normally accumulate across iterations of one user is not available here. 2. **There is nothing to loop.** A step you want repeated has to be either a second arrival — more schedule — or a controller nested inside the single iteration. 3. **An iteration that runs long raises concurrency, silently.** Adding steps to the iteration does not change the arrival schedule, so the same schedule now keeps more threads alive at once with no field anywhere recording that. 4. **The tail is interrupted.** Because the group terminates threads when the schedule ends, a long iteration is also the thing most likely to be cut off, which is what a trailing `pause(...)` is for. ## Reading it in the .jmx The element is written under the alias `OpenModelThreadGroup`, with `OpenModelThreadGroupGui` as its GUI class, and it carries its schedule under the property name `OpenModelThreadGroup.schedule` (with the seed alongside it as `OpenModelThreadGroup.random_seed`). A reviewer scanning a plan can tell an open-model group from any other thread group by the absence of a thread count in the XML — the load lives entirely in the schedule string. ## In the logs Two strings help when you are watching a run: - the starter thread renames itself `open-model-thread-starter-<group name>-<index>`, so you can find it in a thread dump; - the group logs `Starting OpenModelThreadGroup#<index> with schedule <text>` at start, which is the fastest way to confirm which profile a headless run actually used after property substitution. ## The common wrong answers - "It loops until the schedule ends" — no; the schedule keeps producing *new* arrivals, and each of those is a new thread doing one iteration. - "Set Loop Count to control it" — there is no such field on this element. - "The pool size caps concurrency" — the pool is unbounded; it caches idle threads for reuse rather than limiting live ones.

How would you repeat a step several times within one Open Model Thread Group arrival?
With a controller nested inside the iteration, since the thread itself runs the group's children exactly once. The alternative is to express the repetition as more arrivals in the schedule, which changes the applied rate rather than the work each arrival does.
You added three samplers to the iteration and left the schedule alone. What changes at run time?
The arrival schedule is unchanged, so the same instants are still scheduled, but each thread now lives longer and more of them overlap. Nothing on the element records or caps that, and the longer iteration is also more likely to be interrupted when the schedule ends.

saying these in an interview costs you the question

Says a thread loops until the schedule ends
Looks for a Loop Count field on this element
Thinks the cached pool caps live threads
Expects per-thread state to survive between arrivals
Assumes a longer iteration cannot change concurrency

How many iterations does one thread run in JMeter's Open Model Thread Group?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

One arrival, one thread, one iteration

Where the thread count comes from

What follows for a plan

Reading it in the .jmx

In the logs

The common wrong answers

▾common follow-ups2 questions

▾red flags5 flags

One arrival, one thread, one iteration

Where the thread count comes from

What follows for a plan

Reading it in the .jmx

In the logs

The common wrong answers

answer

go deeper