skip to content

Which thread groups does a stock Apache JMeter 6 download actually ship?

level: juniorimportance: must knowfreq 62%

answer

  1. Open the Threads menu and count
  2. Two of them only bracket the run
  3. One core group takes a schedule expression
  4. Prefixed element names are never Apache's
  5. A single jar supplies all five extras

basics

~10 s

Four: Thread Group, setUp Thread Group, tearDown Thread Group and Open Model Thread Group. The Concurrency, Arrivals, Free-Form Arrivals, Ultimate and Stepping groups are third-party, from the jpgc-casutg add-on.

solid answer

~40 s

A freshly unpacked Apache JMeter 6.0.0 offers exactly four entries under **Add > Threads (Users)**: `Thread Group`, `setUp Thread Group`, `tearDown Thread Group` and `Open Model Thread Group` (the last one core since 5.5). Everything else people call a thread group - **bzm - Concurrency Thread Group**, **bzm - Arrivals Thread Group**, **bzm - Free-Form Arrivals Thread Group**, **jp@gc - Ultimate Thread Group** and **jp@gc - Stepping Thread Group** - comes from a single third-party jar: the *Custom Thread Groups* plugin, catalogue id `jpgc-casutg`, published as `kg.apc:jmeter-plugins-casutg`. You install it by putting the jar in `lib/ext` or by using the Plugins Manager, which is itself an add-on. The `bzm - ` and `jp@gc - ` name prefixes are the giveaway: Apache's own elements never carry one.

go deeper

for a junior

Recall the four stock entries under Add > Threads (Users) and remember that a bzm - or jp@gc - prefix means the element came from a jar somebody installed.

for a middle

Explain that a .jmx stores these elements under their class names, so the dependency is on the classpath of every machine that opens the plan, not just the one that runs it.

for a senior

Show you check for the add-on before trusting an inherited plan: list lib/ext, grep the .jmx for kg.apc and com.blazemeter, and confirm the version rather than assuming any version will do.

for a principal

Own the position that a plan file which cannot be opened without a community jar is a coupling decision, and say what your organisation does to make that jar present and pinned everywhere plans are authored and run.

## The four elements a bare install offers Unpack `apache-jmeter-6.0.0`, start the GUI, right-click the Test Plan and open **Add > Threads (Users)**. Four entries appear, and that is the whole list: - **Thread Group** - `org.apache.jmeter.threads.ThreadGroup`, the ordinary one. - **setUp Thread Group** - `org.apache.jmeter.threads.SetupThreadGroup`, runs to completion before the regular groups. - **tearDown Thread Group** - `org.apache.jmeter.threads.PostThreadGroup`, runs after they finish. - **Open Model Thread Group** - `org.apache.jmeter.threads.openmodel.OpenModelThreadGroup`, a core component since JMeter 5.5, driven by a `Schedule` expression. You can confirm the list without opening the GUI. `bin/saveservice.properties`, the file that maps the short XML tags in a `.jmx` to Java classes, carries aliases for exactly those four (plus one long-obsolete `ReflectionThreadGroup` entry that `bin/upgrade.properties` retires to `ObsoleteGui`). ## Where the other five come from The groups people reach for when a single linear ramp is not enough all live in one third-party jar: | Name in the tree | Class | Supplied by | |---|---|---| | bzm - Concurrency Thread Group | `com.blazemeter.jmeter.threads.concurrency.ConcurrencyThreadGroup` | jpgc-casutg | | bzm - Arrivals Thread Group | `com.blazemeter.jmeter.threads.arrivals.ArrivalsThreadGroup` | jpgc-casutg | | bzm - Free-Form Arrivals Thread Group | `com.blazemeter.jmeter.threads.arrivals.FreeFormArrivalsThreadGroup` | jpgc-casutg | | jp@gc - Ultimate Thread Group | `kg.apc.jmeter.threads.UltimateThreadGroup` | jpgc-casutg | | jp@gc - Stepping Thread Group | `kg.apc.jmeter.threads.SteppingThreadGroup` | jpgc-casutg | The plugin's catalogue id is **`jpgc-casutg`**, its display name is **Custom Thread Groups**, and it is published to Maven Central as `kg.apc:jmeter-plugins-casutg` (3.1.1 is the current release). One jar carries all five groups, their GUI panels, and the `VirtualUserController` that the dynamic ones use as their sampler controller. It reaches a machine either as a jar dropped into `lib/ext`, or through the **Plugins Manager** - itself a separate third-party jar, `jpgc-plugins-manager`, whose only visible effect on a bare install is a new item in the **Options** menu. ## The prefixes are the tell Both prefixes are hard facts about the code, not conventions someone typed in: 1. `jp@gc - ` is prepended by `JMeterPluginsUtils.prefixLabel()`, which every `kg.apc` GUI calls from `getStaticLabel()`. 2. `bzm - ` is returned literally by the BlazeMeter-contributed GUIs, for example `ConcurrencyThreadGroupGui.getStaticLabel()`. 3. Apache's own GUIs resolve their label from `messages.properties` keys such as `threadgroup` and `setup_thread_group_title`, which contain no prefix at all. So an element whose displayed name starts with `bzm - ` or `jp@gc - ` is, without exception, an element whose class is not in the Apache download. ## Why an interviewer asks this Most people meet JMeter on a machine somebody else set up, where the add-on is already present, and they never learn that half the menu is not Apache's. The consequence is not cosmetic. Because a `.jmx` records these elements under their fully-qualified class names, a plan built on them cannot be opened at all on a stock install - it is a hard dependency, not a graceful degradation. Knowing which side of that line an element sits on is the difference between a plan that a colleague can run and one that fails before the first sample. ## What to check on a machine you inherit - List `lib/ext` and look for `jmeter-plugins-casutg-*.jar`. - Open the **Options** menu: a Plugins Manager entry means the manager jar is installed. - Grep the `.jmx` for `kg.apc` and `com.blazemeter` to see which add-on classes the plan needs. - Run `PluginsManagerCMD status` if the manager and its `cmdrunner` dependency are present.

  • What do the bzm - and jp@gc - prefixes on a JMeter element name tell you?
    That the element's class is not in the Apache download. `jp@gc - ` is prepended by `JMeterPluginsUtils.prefixLabel()` for the `kg.apc` components; `bzm - ` is returned literally by the BlazeMeter-contributed GUIs. Apache's own elements take their label from `messages.properties` and carry no prefix, so a prefix is a reliable marker of a third-party jar.
  • Which single add-on supplies the Concurrency, Arrivals, Ultimate and Stepping thread groups?
    The Custom Thread Groups plugin, catalogue id `jpgc-casutg`, published as `kg.apc:jmeter-plugins-casutg` (3.1.1 current). One jar holds all five thread groups, their GUIs and the `VirtualUserController` the dynamic ones use, so installing or removing it moves all of them at once.

saying these in an interview costs you the question

  • Says the Concurrency Thread Group ships with Apache JMeter
  • Treats jp@gc and bzm elements as core JMeter components
  • Cannot name the add-on that supplies the extra groups
  • Assumes any .jmx will open on any JMeter install
  • Thinks the Open Model Thread Group is a plugin