In a JMeter test plan, what does adding an HTTP Cookie Manager change about the requests sent?
answer
- Ask what a browser does automatically
- Per thread, not per plan
- The table is not the store
- A policy field and an implementation field
basics
~20 sAn HTTP Cookie Manager gives every JMeter thread its own cookie store: it saves the cookies a response sets and replays the matching ones on later requests to that site, so each thread holds a separate session.
solid answer
~40 sThe HTTP Cookie Manager is a Config Element that makes the HTTP samplers in its scope behave like a browser's cookie jar. Each JMeter thread gets its own storage area, so 200 threads log in as 200 independent sessions rather than trampling one another. Received cookies are checked against the request URL before being stored, which is why cross-domain cookies are dropped unless you set `CookieManager.check.cookies=false`. The **Cookie Policy** field selects the HttpClient cookie specification — `standard` since 3.0, and `ignoreCookies` is equivalent to leaving the element out — while **Implementation** is `HC4CookieHandler`. Cookies picked up at run time never show in the element's table; you read them in a View Results Tree. Rows typed into the table by hand are used by every thread and are given an expiry far in the future.
go deeper
Recall that the element exists, that you add it once per Thread Group, and that without it every request is anonymous.
Explain that the store is per thread, that received cookies never show in the table, and what Cookie Policy and Implementation select.
Show you would check cookie expiry and iteration clearing before blaming the server when a long run starts returning login pages.
Own the call on whether threads model returning or first-time visitors, and make that setting explicit in every plan a team ships.
## What the element actually is The **HTTP Cookie Manager** is a Config Element. Drop it into a Thread Group and every HTTP Request in its scope gains browser-like cookie handling: the cookies a response sets are parsed and stored, and the matching ones are attached to later requests to the same site. The sampler itself does not change — the manager is consulted around it. The store is **per thread**. Each JMeter thread carries its own cookie storage area, so a plan with 200 threads logging in produces 200 independent sessions instead of one session overwritten 200 times. This is the usual reason a plan that "works for one user" collapses under load when the element is missing: without it every request is anonymous, and a server that redirects unauthenticated traffic sends every thread to the login page. ## What you can and cannot see Cookies received during the run **never appear in the element's table**. That table is input, not state. To see what a thread is actually holding, add a View Results Tree and read the request headers of a later sample. Rows you type into the table by hand behave differently: - they are used by **every** thread, not by one; - they are created with an expiry far in the future; - names must be unique — a second row with the same name replaces the first; - a row with a null or empty value is dropped, unless `CookieManager.delete_null_cookies=false`. ## The fields that change behaviour | Field | What it does | |---|---| | `Clear cookies each iteration` | At the start of each main Thread Group iteration, resets the thread's store to just the hand-typed rows | | `Use Thread Group configuration to control cookie clearing` | Hands that decision to the Thread Group instead of the checkbox above | | `Cookie Policy` | Selects the HttpClient cookie specification; `standard` since 3.0, `ignoreCookies` disables the element in effect | | `Implementation` | `HC4CookieHandler` (HttpClient 4.5.x), the default since 3.0 | Five JMeter properties sit behind the element and are set in `bin/user.properties`, never in the GUI. One you have already met — `CookieManager.delete_null_cookies` above; a fifth, `CookieManager.name.prefix`, only names the variables that saving writes. The other three: 1. `CookieManager.check.cookies` — default `true`; received cookies are validated against the request URL, which is why cross-domain cookies are not stored; 2. `CookieManager.allow_variable_cookies` — default `true`; lets a cookie value carry a `${...}` reference; 3. `CookieManager.save.cookies` — default `false`; copies stored cookies into thread variables. ## Where it bites Two cases account for most of the incidents. **More than one Cookie Manager in scope of a sampler.** The manual is blunt about it: there is no way to say which one is used, and a cookie stored in one is invisible to the other. Keep one per Thread Group. **Expiry on a long run.** Apache JMeter 6.0.0 lists exactly one incompatible change and it is this element: a cookie is no longer sent once its expiry time has passed. Earlier versions replayed expired cookies indefinitely, which quietly kept a session alive past the point the server intended. A run that outlives the cookie now starts collecting login redirects or authentication failures unless the plan re-authenticates or refreshes the session itself. If you inherit a plan that "used to run all night", check this first. ## The second-iteration effect Because the store survives an iteration by default, the second pass through a Thread Group loop is not a fresh visitor. The session cookie is already there, so the login sampler is being replayed by a thread that is already authenticated — a materially different request from the one a first-time visitor makes, and often a much cheaper one. That is a modelling choice rather than a bug, but it is a choice you have to make deliberately by deciding whether `Clear cookies each iteration` is ticked. Left alone, it is not ticked on a newly added element.
- Does a JMeter Cookie Manager keep sending a cookie after its expiry time has passed?Not in JMeter 6.0.0. That release stopped sending expired cookies; before it, they were replayed indefinitely. A run long enough to outlive the cookie can therefore start failing on session or authentication, so the plan has to re-authenticate or refresh the session itself.
- What happens if two HTTP Cookie Managers are in scope of the same JMeter sampler?There is no way to specify which one is used, and a cookie stored in one is not visible to the other. The manual warns against it outright. Keep a single Cookie Manager per Thread Group and put shared cookies in that one.
- Which Cookie Policy value makes a JMeter Cookie Manager behave as though it were absent?`ignoreCookies`. The manual notes it is equivalent to omitting the Cookie Manager — nothing is stored and nothing is sent. The default since 3.0 is `standard`, which handles most sites.
saying these in an interview costs you the question
- Says all JMeter threads share one cookie jar
- Thinks cookies received at run time appear in the element's table
- Hand-writes a Cookie header in a Header Manager instead
- Believes cross-domain cookies are stored by default
- Assumes an expired cookie is still replayed by JMeter 6