Pre-Processors, Post-Processors, Extractors, and Correlation: Core Concepts and Mental Model

1. Why recorded tokens make invalid multi-user scripts

A browser recording often captures a concrete CSRF token, order ID, request ID, or session handle. Replaying that literal value may work for one request and fail as soon as the server rotates state or several users execute concurrently. Worse, a test can send the same captured session identity from every JMeter thread and accidentally benchmark one shared server-side session.

2. Mental model: correlation follows causality

flowchart TD
A[Sampler A: start session] --> R[Response contains synthetic token]
R --> X[Post-Processor / extractor]
X --> V[Thread-local CORR_TOKEN]
V --> P[Pre-Processor prepares PREPARED_TOKEN]
P --> B[Sampler B: use session]
B --> T[Authorized local target]
T --> RR[Response / status]
RR --> Q[Assertion verifies accepted]
V -. thread 1 copy .-> U1[Virtual user 1]
V -. separate thread 2 copy .-> U2[Virtual user 2]

Sampler A must complete before its Post-Processor can read the response. The extractor writes CORR_TOKEN into the current thread's JMeter variable map. Immediately before Sampler B, a Pre-Processor reads that same thread's token and derives PREPARED_TOKEN. Sampler B sends both values. An assertion then verifies the business outcome. Thread 1 and thread 2 have separate variable maps, so their correlated values do not overwrite one another.

3. Execution order: scope first, type order second

For one applicable sampler, JMeter's current execution order is: Configuration elements → Pre-Processors → Timers → Sampler → Post-Processors → Assertions → Listeners. A Post-Processor therefore cannot inspect assertion results for the same sample because assertions have not run yet.

Visual sibling order does not turn a Post-Processor into “after the sampler above it.” If a processor is scoped broadly under a controller, it can run for every sampler in that scope. Attach it as a child of the specific sampler when correlation belongs only to that response/request.

4. Pre-Processor versus Post-Processor

5. Correlation values belong in variables, not global properties

Chapter 06 established that JMeter variables are normally thread-local while JMeter properties are shared by the entire JMeter process. A response-derived user token is therefore a variable. Writing it to props or __setProperty creates a cross-thread race and can make users reuse one another's session state.

6. Dedicated extractors should be the default

Current JMeter includes built-in Regular Expression, CSS Selector, XPath/XPath2, JSON Extractor, JSON JMESPath Extractor, and Boundary Extractor Post-Processors. Use the extractor that matches the response format. Dedicated components are easier to review and generally cheaper than arbitrary script code.

This chapter uses JSON JMESPath Extractor with expression session.token. Chapter 10 goes deeper into regex, CSS/JQuery, XPath, JSONPath, and boundary extraction choices.

7. JSON JMESPath Extractor contract

A JSON JMESPath Extractor runs after the sampler in its scope and can store a selected result in a named JMeter variable. Configure:

• Apply to: Main sample only
• Name of created variable: CORR_TOKEN
• JMESPath: session.token
• Match No.: 1
• Default Value: CORR_MISSING

The explicit sentinel is intentional. If the response changes shape, CORR_TOKEN becomes CORR_MISSING rather than silently keeping some stale token.

8. Missing correlation must be observable

Do not let a failed extraction fall through as an unexplained literal ${CORR_TOKEN} or a previous value. During authoring, set a clear default and assert that the extracted variable is not the sentinel. In load mode, preserve the failed sample/JTL and stop or skip the remaining dependent steps according to an explicit error policy.

9. JSR223 PreProcessor is for transformation, not basic extraction

A Pre-Processor is appropriate when the next request requires a derived form that a normal JMeter field/function cannot express clearly. The mandatory lab converts the synthetic token to uppercase only to prove the processor ran before the next sampler:

def token = vars.get('CORR_TOKEN')
if (token == null || token == 'CORR_MISSING' || token.trim().isEmpty()) {
    vars.put('PREPARED_TOKEN', 'PREP_MISSING')
    vars.put('CORRELATION_STATE', 'missing')
} else {
    // Synthetic transformation used only to prove the PreProcessor runs before /session/use.
    vars.put('PREPARED_TOKEN', token.toUpperCase(Locale.ROOT))
    vars.put('CORRELATION_STATE', 'ready')
}

Use Groovy and enable compiled-script caching when scripting is needed. Do not insert ${CORR_TOKEN} directly into cached script text; use vars.get('CORR_TOKEN') so runtime per-thread values are read on every invocation.

10. Body versus header versus cookie correlation

If a token is in JSON, use JSON/JMESPath. If it is in a simple response header, a header-scoped Regex/Boundary extractor may be appropriate. If state is a normal HTTP cookie, Cookie Manager often models it directly and you should not manually extract/reinject it unless the application contract requires special handling.

11. Read-only inspection before changing correlation

• Inspect the successful response and identify the exact dynamic field and owning sampler.
• Search the JMX for hard-coded captured tokens/IDs and note every downstream reference.
• List each Pre/Post-Processor and its tree parent/scope.
• Check extractor reference name, expression, match number, and default.
• Use a one-thread Debug Sampler to inspect only synthetic correlation variables.
• Compare downstream request metadata and target event logs without persisting real secrets.
• Record JTL, jmeter.log, generator headroom, and target behavior before changing load.

12. DevOps connection: correlation is reproducibility

A load plan should work when started later by another developer or CI agent because it discovers dynamic state from the system under test. Hard-coded replay data makes a plan dependent on one historical session. Proper correlation turns the JMX into a repeatable protocol workflow.

Knowledge check

Official references and version notes

• Elements of a Test Plan — Pre-Processor/Post-Processor purpose, scope, and execution order: configuration → pre-processors → timers → sampler → post-processors → assertions → listeners.
• Component Reference — Regular Expression, JSON/JMESPath, Boundary, JSR223 Pre/Post Processor, User Parameters, and Result Status Action Handler semantics.
• Functions and Variables — thread-local JMeter variables versus process-wide JMeter properties.
• Best Practices — CLI load execution and scripting/performance guidance.
• Apache JMeter downloads — current stable release and Java requirement.