In JMeter, how do the Stop Thread, Stop Test and Stop Test Now error actions differ?

## Three different blast radii All three are values of the same Thread Group field, **Action to be taken after a Sampler error**, and all three are applied at the same moment — after the failing sample has been through its post-processors, assertions and listeners. What separates them is scope and courtesy. | Action | Who stops | In-flight samplers | Engine call | |---|---|---|---| | `Stop Thread` | the failing thread only | it has already finished | none — a local flag | | `Stop Test` | every thread in every group | allowed to finish | `askThreadsToStop()` | | `Stop Test Now` | every thread in every group | interrupted where possible | `stopTest()` | ### Stop Thread The thread sets its own `running` flag false. The loop that was feeding it samplers exits, the thread's `threadFinished` hook runs and the JVM thread ends. Nothing else in the plan notices, except that the group now has one fewer active thread. This is the narrowest of the three and the only one that leaves the run itself intact. ### Stop Test The thread asks the engine for a clean shutdown. The engine walks every thread group and sets the stop flag on each of its threads. No interrupt is issued, so a thread parked in a socket read on a slow endpoint keeps waiting until that request completes or times out on its own. Only then does it notice the flag and exit. A run stopped this way can therefore take as long as the slowest outstanding request to actually finish. ### Stop Test Now The thread asks the engine for a hard shutdown. For every thread the engine calls the JMeter thread's `stop()`, then its `interrupt()`, then interrupts the underlying JVM thread. The middle step is the interesting one: it only does anything when the sampler currently executing implements `Interruptible`. If it does not, JMeter logs `Sampler is not Interruptible` and that thread still has to finish naturally. The manual is careful about this too - 'any current samplers are interrupted **if possible**'. After issuing the interrupts the engine pauses briefly and checks whether the threads really died. If some survived, in GUI mode a message is displayed; in CLI mode JMeter treats it as a fatal failure to stop. ## Things that are true of all three - The sample that triggered the action is already recorded. Listeners are notified before the action is applied, so the failing row reaches the results file with its real verdict. - The trigger is the final verdict, so an assertion failure stops a thread or a run just as a connection reset would. - `jmeterengine.threadstop.wait` (default `5000`, in milliseconds) is the deadline the engine gives a thread to die. ## Choosing between them 1. Reach for `Stop Thread` when the failure makes only *this* virtual user's remaining work meaningless — it has no session, no order id, nothing to continue with. 2. Reach for `Stop Test` when the failure means nobody's remaining work is meaningful, and you would rather have a clean, complete set of results up to that point. 3. Reach for `Stop Test Now` only when waiting for in-flight requests is itself the problem — an endpoint that is hanging rather than failing, for instance. It is the one choice that can leave samplers half-measured, and on a run whose samplers are not `Interruptible` it is not actually faster than `Stop Test`. A useful sanity check when reading someone else's plan: `Stop Test` and `Stop Test Now` hand a single thread the power to end everybody's run. If the plan has hundreds of threads and any one failure can trip it, the run's duration becomes a property of the flakiest endpoint rather than of the schedule.