skip to content

In JMeter, how do you make the HTTP Cookie Manager expose received cookies as thread variables?

level: middleimportance: nice to knowfreq 28%

answer

  1. Not a checkbox on the element
  2. A property file, read at startup
  3. The variable name gains something
  4. One key switches it, another names it

basics

~10 s

Set CookieManager.save.cookies=true in bin/user.properties before JMeter starts. Every cookie the manager stores is then written to a thread variable carrying the COOKIE_ prefix, so a cookie named TEST is read as ${COOKIE_TEST}.

solid answer

~40 s

This is a JMeter **property**, not a checkbox on the element — nothing in the HTTP Cookie Manager panel turns it on. `CookieManager.save.cookies` ships commented out with a default of `false`; set it to `true` in `bin/user.properties` or pass `-JCookieManager.save.cookies=true`. Each cookie the manager stores while sampling is then copied into a JMeter variable in that thread's context, named with the prefix from `CookieManager.name.prefix`, which defaults to `COOKIE_`. So a `JSESSIONID` cookie becomes `${COOKIE_JSESSIONID}`. The prefix value is trimmed, which is why the manual tells you to define it as one or more spaces to remove it. The flag is read once when the `CookieManager` class loads, so setting it from a script during the run has no effect.

code

properties · 4 lines
properties
# bin/user.properties - read at startup, not during the run
CookieManager.save.cookies=true
# default prefix; define as one or more spaces to remove it
CookieManager.name.prefix=COOKIE_

go deeper

for a junior

Recall that JMeter can expose cookies as variables and that it is switched on in a properties file, not in the GUI.

for a middle

Explain the two property keys, the default prefix, and why the setting has to be in place before the run starts.

for a senior

Know that the variables are per thread and rewritten on each store, and choose this over an extractor only when the value really is a cookie.

for a principal

Decide whether injector-wide properties like this belong in a shared user.properties the whole team ships, since a plan alone will not carry them.

## The mechanism When the HTTP Cookie Manager stores a cookie, it normally keeps it only in the thread's cookie store, invisible to the plan. Turning on `CookieManager.save.cookies` adds one more step: as each cookie is added, and provided sampling has started, the manager writes the cookie's value into a JMeter variable in that thread's context. The variable name is the cookie name with a prefix in front of it. The prefix comes from `CookieManager.name.prefix` and defaults to `COOKIE_`, which exists so that a cookie called `path` or `count` cannot quietly overwrite a variable of yours. ## Getting it switched on Both keys are read through JMeter's property lookup **once**, into static fields, when the `CookieManager` class is first loaded. That has a practical consequence: 1. `bin/user.properties` works — it is read at startup, well before any test element class loads; 2. `-JCookieManager.save.cookies=true` on the command line works, for the same reason; 3. a JSR223 or `__setProperty` call during the run does **not** work — the field was already initialised, and nothing re-reads it. The `CookieManager` class logs what it resolved as it loads — `Settings: Delete null: … Check: … Allow variable: … Save: … Prefix: …` in `jmeter.log` — so that one line is the fastest confirmation the flag took. It appears when the first Cookie Manager is instantiated, not at process start. ## The prefix | Property | Default | Effect | |---|---|---| | `CookieManager.save.cookies` | `false` | Whether stored cookies are copied into variables at all | | `CookieManager.name.prefix` | `COOKIE_` | What is prepended to the cookie name to form the variable name | The value read for the prefix is trimmed, so defining it as one or more spaces yields an empty prefix and `${TEST}` addresses a cookie named `TEST` directly. The manual recommends that spelling; it is also why you cannot use a prefix that ends in a space. ## Scope, and what this is not The variables are ordinary JMeter variables in the thread's own context. They are **per thread**, exactly like the cookie store that produced them, so nothing crosses between virtual users and nothing is visible to another Thread Group. They are also rewritten whenever the cookie is re-stored, so they track the current value rather than freezing the first one. What this is not: a general-purpose way to lift a value out of a response body. It only ever sees cookies the Cookie Manager itself stored, which means the response must have set them and they must have passed the manager's validity check. Anything that arrives in a JSON payload or an HTML form field is a different problem with different elements. ## When it earns its keep - Echoing a session identifier into a request body or a custom header that the server expects in a place cookies do not reach. - Writing the session identifier into a sample label or an assertion so a failed sample can be traced back to a specific server-side session. - Debugging a plan where you suspect two samplers are running under different sessions: print the variable and watch it change. It is a small feature, and most plans never need it — which is exactly why an interviewer asking about it is probing whether you know the Cookie Manager has properties behind it at all, rather than testing something you use every week.

  • Why does setting CookieManager.save.cookies from a JMeter script at run time have no effect?
    The flag is read once into a static field when the `CookieManager` class is loaded, so nothing re-reads it later. Put it in `bin/user.properties`, or pass `-JCookieManager.save.cookies=true`, so the value is in place before that class loads.
  • Are the variables a JMeter Cookie Manager writes visible to other threads?
    No. They are ordinary JMeter variables in the thread's own context, exactly like the cookie store that produced them. Another thread logged in as a different user has its own values, and nothing crosses between them.

saying these in an interview costs you the question

  • Looks for the option on the Cookie Manager panel
  • Sets the property with __setProperty during the run
  • Forgets the prefix when referencing the variable
  • Expects the variable to be visible to other threads
  • Assumes the prefix is configurable per element