skip to content

In JMeter's Thread Group, what stops a thread first: Loop Count or the scheduler's Duration?

level: middleimportance: must knowfreq 71%

answer

  1. Two limits, not one governing setting
  2. A checkbox gates the lower two boxes
  3. Loops must not run out first
  4. Infinite is stored as minus one

basics

~20 s

Whichever limit is reached first. JMeter stops a thread when its Loop Count is exhausted or the scheduler's Duration expires, so a finite Loop Count can end a run long before a scheduled hour is up.

solid answer

~40 s

Both are stop conditions and JMeter honours whichever arrives first. `Duration (seconds):` and `Startup delay (seconds):` are only consulted when the `Specify Thread lifetime` checkbox is ticked — that checkbox is `ThreadGroup.scheduler`, and until it is ticked the two fields are greyed out and ignored. To hold a group for a fixed hour you therefore need two settings, not one: tick `Specify Thread lifetime` and set `Duration (seconds): 3600`, **and** tick `Infinite` next to `Loop Count` so the loops never run out first. `Infinite` stores a loop count of `-1`. Leaving `Duration` blank with the checkbox ticked is not neutral: JMeter treats the empty value as zero, rejects it and stops the test with an `Invalid duration 0 set in Thread Group` error.

code

text · 9 lines
text
Thread Properties
  Number of Threads (users): 200
  Ramp-up period (seconds):  300
  Loop Count:                [x] Infinite        <- stored as -1
  [ ] Same user on each iteration
  [ ] Delay Thread creation until needed
  [x] Specify Thread lifetime                    <- ThreadGroup.scheduler = true
      Duration (seconds):      3600
      Startup delay (seconds): 0

go deeper

for a junior

Remember that Loop Count and Duration are both able to end a thread and that the lower two boxes do nothing until Specify Thread lifetime is ticked. Recognise the greyed-out fields as the sign the scheduler is off.

for a middle

Explain the whichever-comes-first rule and be able to list the exact settings that make a group hold for a fixed hour, including ticking Infinite so the loops cannot expire first.

for a senior

Notice the failure mode in someone else's plan: a scheduled run that ends early, or a thread count that decays because some threads exhausted their loops while others kept going.

for a principal

Decide how the team encodes run length across plans so that scheduled runs are comparable, and make sure a plan cannot silently pass a shorter run off as the agreed one.

## Two independent stop conditions A JMeter thread in the stock Thread Group ends for one of two ordinary reasons: - it has completed the number of iterations given by `Loop Count`, or - the scheduler is enabled and the group's scheduled end time has arrived. The component reference states the rule directly: JMeter runs the thread group until either the number of loops is reached or the duration is reached, **whichever occurs first**. Nothing arbitrates between them and neither field overrides the other, which is why a plan can be configured for an hour and be finished in nine seconds. ## The checkbox that switches the scheduler on `Duration (seconds):` and `Startup delay (seconds):` are inert until `Specify Thread lifetime` is ticked. In the GUI the two text fields and their labels are literally disabled while the box is clear; in a saved plan the box is the boolean `ThreadGroup.scheduler`, and when it is `false` the engine never assigns a start or an end time to the group's threads at all. A very common report of "my Duration is ignored" is simply this checkbox left clear. The two scheduler fields are relative, not absolute. `Startup delay` is the number of seconds JMeter waits before starting the group; `Duration` is the number of seconds the group is then allowed to run. JMeter 6.0.0's panel has no absolute start-time or end-time boxes — old plans may still carry `ThreadGroup.start_time` and `ThreadGroup.end_time` entries, but the current element does not read them. ## Making Duration the limit that governs For a group of 200 users started over five minutes and held for a fixed hour: 1. set `Number of Threads (users): 200` and `Ramp-up period (seconds): 300`; 2. tick `Infinite` beside `Loop Count` — otherwise the finite count wins; 3. tick `Specify Thread lifetime`; 4. set `Duration (seconds): 3600`; 5. leave `Startup delay (seconds): 0` unless the group is meant to begin after another one. Skip step 2 and the group runs one iteration per thread and exits, which on a fast plan can take seconds. Skip step 3 and the `3600` you typed is never read. Both mistakes produce a run that looks configured for an hour and is not. ## What blank and zero values do | setting | value | effect | |---|---|---| | `Loop Count` | `1` (default) | each thread runs the plan once and exits | | `Loop Count` | `Infinite` | stored as `-1`; only the scheduler or a manual stop ends the thread | | `Specify Thread lifetime` | clear (default) | `Duration` and `Startup delay` are disabled and ignored | | `Duration (seconds):` | blank or `0` with the box ticked | the test is stopped with `Invalid duration 0 set in Thread Group` | | `Startup delay (seconds):` | blank or `0` | the group starts immediately | ## When the end is actually noticed The scheduled end is checked **between samples**. JMeter does not interrupt a sampler that is already waiting for a response, so a group whose `Duration` has expired can keep running until its slowest in-flight request returns or times out; the manual warns that the end time may therefore be delayed arbitrarily. With the scheduler on, JMeter will also refuse to serve a timer pause that would finish after the scheduled end, stopping the thread instead of sleeping past the deadline. ## Common mistakes - Typing a `Duration` and never ticking `Specify Thread lifetime`. - Leaving `Loop Count` at its default of 1 and expecting the scheduler to keep the threads alive. - Setting a huge `Loop Count` instead of ticking `Infinite`, so a fast plan still finishes early on some threads and the concurrency quietly decays. - Expecting the group to stop on the exact second, when the end is only observed between samples. - Assuming `Startup delay` extends the run; it shifts the whole group later, and the `Duration` clock starts after it.

  • You tick Specify Thread lifetime in a JMeter Thread Group but leave Duration blank. What happens?
    The run fails fast. JMeter reads the empty `ThreadGroup.duration` as zero, refuses it, and stops the test with `Invalid duration 0 set in Thread Group: <name>`. A blank value is not read as "no limit" once the scheduler is enabled.
  • Does the scheduler's Startup delay make a JMeter Thread Group run longer?
    No. `Startup delay (seconds):` shifts the whole group later; the `Duration` clock starts once the delay has elapsed. Its normal use is staggering one group behind another in the same plan, not extending either group's run.
  • Why does setting Loop Count to a very large number behave differently from ticking Infinite?
    A large finite count can still be exhausted. On a fast plan the quicker threads reach the count and exit while others continue, so concurrency decays before the scheduled end. `Infinite` stores `-1`, which never runs out, leaving the scheduler as the only stop condition.

saying these in an interview costs you the question

  • Says the scheduler's Duration always overrides Loop Count.
  • Types a Duration without ticking Specify Thread lifetime.
  • Expects a default Loop Count of 1 to survive a scheduled hour.
  • Thinks a blank Duration with the scheduler on simply means no limit.
  • Claims the group stops on the exact second the Duration expires.