Variables Versus Properties

JMeter stores parameter values in two places that look almost identical inside a plan and behave nothing alike once threads are running. Telling them apart is the single most reliable discriminator in a JMeter interview, because almost every "it worked with one thread and broke with fifty" story traces back to the wrong one being used. ## Two stores with different owners A **variable** lives in a `JMeterVariables` object. `JMeterContextService` keeps the per-thread context in a `ThreadLocal`, so every thread a Thread Group starts is handed its own `JMeterVariables` instance. When thread 7 writes `sessionToken`, it writes into thread 7's map and nowhere else. Threads 1 through 6 cannot see the value, cannot overwrite it, and are not slowed down by it. A **property** lives in one static `Properties` object held by `JMeterUtils`. There is exactly one of these per JVM for the whole run. Every thread in every Thread Group reads and writes the same entries, and a value written at 10 seconds into the run is still there at 10 minutes. ## Reading and writing each one | | Variable | Property | |---|---|---| | Read syntax | `${varName}` | `${__P(name,default)}` | | Visible to | one thread | every thread in the JVM | | Typical source | `User Defined Variables`, an extractor, a `Counter` | `jmeter.properties`, `user.properties`, `${__setProperty(...)}` | | Lifetime | the thread that owns it | the whole run | | Two threads writing the same name | independent copies | last writer wins | The syntax is the giveaway in a plan review. A bare `${name}` is always a variable lookup. A property is never reachable that way — it needs the `__P` function, because the property map is a different object entirely. ## A run-wide base URL versus a per-thread session token The worked case that makes the split obvious is a plan that hits a staging host and logs each virtual user in. - The **base URL** is one value the entire run should agree on. It is chosen before the run starts, nothing in the plan changes it, and every thread wants the identical string. That is a **property**: put `base.url=https://shop.internal.example` in a property file and read it as `${__P(base.url,http://localhost:8080)}`. - The **session token** is produced during the run, belongs to exactly one simulated user, and is meaningless to any other thread. That is a **variable**: an extractor writes `sessionToken` into the thread's own map and later samplers read `${sessionToken}`. Invert the two and both break, but only one breaks loudly. A base URL kept in a variable merely has to be repeated in every Thread Group. A session token kept in a property is overwritten by whichever thread logged in most recently, so threads start sending each other's token. With one thread it passes every time. With fifty it fails intermittently and the failure moves around, which is why this shows up as a debugging story rather than a design review finding. ## What the split rules out - A variable cannot be used to hand a value from one thread to another. There is no shared variable; there are N private copies. - A property cannot hold anything that differs per simulated user, because there is only one slot for the key. - `${__P(name)}` will not find a `User Defined Variables` entry, and `${varName}` will not find a property file entry. They read different maps. - Nothing in a variable survives the run. Nothing in a property is private. ## Where the values come from Properties are seeded from files that JMeter reads at startup and can also be written during the run with `${__setProperty(name,value)}`, which is how a plan publishes a value from one thread to all the others. Variables are seeded per thread by a `User Defined Variables` config element, and are then added to during the run by extractors and by elements such as `Counter` and `Random Variable`, all of which write their output into the calling thread's own variables map. This is worth stating explicitly because it catches people out: even `Counter`, which can be configured so that all threads advance one shared sequence, still delivers its result as a per-thread **variable**. The sharing is in the counting, not in the storage. Whenever you see a value arriving as `${something}` in a plan, it is a variable and therefore private to the thread reading it, whatever produced it.