skip to content

Plugin Thread Groups

3 roadmaps6 questions

The Concurrency, Arrivals, Ultimate and Stepping thread groups ship as a third-party add-on, not with Apache JMeter. Interviewers probe whether you know what a stock install really has.

on this pageshow

explore

questions

6

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
open as a page

In JMeter's bzm - Concurrency Thread Group, what does Ramp-Up Steps Count 5 do?

level: middleimportance: must knowfreq 57%

basics

~10 s

It cuts the ramp into five equal landings. With Target Concurrency 500 and Ramp Up Time 300 seconds the group holds 100, then 200, 300, 400 and finally 500 threads, sixty seconds per landing.

open as a page

How does JMeter's jp@gc - Stepping Thread Group express a stepped profile?

level: middleimportance: should knowfreq 41%

basics

~20 s

As a fill-in-the-blank sentence: start this many threads, first wait, then start a burst, next add a portion every so many seconds using a ramp-up, then hold load, finally stop a portion every so many seconds.

open as a page

A JMeter plan using bzm - Concurrency Thread Group will not open on a fresh install. Why?

level: seniorimportance: should knowfreq 49%

basics

~10 s

The .jmx stores that element under its fully-qualified class name, and a stock install has no such class. JMeter cannot resolve it, so the whole plan fails to load rather than losing one element.

open as a page

How would you decide whether a team's JMeter plans may depend on the Custom Thread Groups add-on?

level: principalimportance: should knowfreq 31%

basics

~20 s

Weigh what the add-on expresses that stock elements cannot against the cost: every machine that opens or runs a plan needs the same pinned jar, and without it the plan will not load at all.

open as a page

How do you drive JMeter's Ultimate Thread Group schedule from a property?

level: middleimportance: nice to knowfreq 21%

basics

~20 s

Set the JMeter property threads_schedule to a list of spawn(threads, initialDelay, startupTime, holdLoadFor, shutdownTime) directives. When that property is non-empty the element logs that the GUI profile will be ignored and builds its table from the property.

open as a page