skip to content

In JMeter, what does the httpclient4.retrycount property retry, and what does it not?

level: seniorimportance: should knowfreq 48%

answer

  1. Transport-level only, never a returned response
  2. Idempotent methods unless you widen it
  3. Default zero on both implementations
  4. Read once, so it is JVM-wide
  5. No retry element ships with JMeter

basics

~20 s

It retries transport failures only - an I/O error while the request is executing, on idempotent methods. It never re-sends a request the server answered, and never re-runs a sampler an assertion failed. It defaults to 0.

solid answer

~40 s

`httpclient4.retrycount` is a JMeter property, default `0`, that JMeter hands to Apache HttpClient 4's `StandardHttpRequestRetryHandler`. It is a **transport-level** retry: it covers an I/O failure that happens while the request is being executed, and by default only for idempotent HTTP methods. Setting `httpclient4.request_sent_retry_enabled=true` widens it to requests that were already sent, idempotent or not. What it does *not* cover is everything most people hope it does — a response the server actually returned, however unwelcome; a sampler an assertion marked failed; a missing extraction. The value is read once into a static field when the HTTP implementation class initialises, so it is a JVM-wide setting rather than a per-sampler or per-Thread-Group one. The Java implementation has its own equivalent, `http.java.sampler.retries`, also `0`.

code

properties · 8 lines
properties
# user.properties - HttpClient4 transport retries
httpclient4.retrycount=3

# widen from idempotent methods to every method (use with care)
httpclient4.request_sent_retry_enabled=true

# the Java implementation keeps its own, unrelated count
http.java.sampler.retries=0

go deeper

for a junior

Remember that the default is zero, so out of the box JMeter retries nothing, and that the property lives in a properties file rather than on a sampler.

for a middle

Explain that it is handed to HttpClient's retry handler, covers transport I/O failures on idempotent methods, and is widened by request_sent_retry_enabled.

for a senior

Diagnose the common misuse: someone raises it hoping to mask application-level failures, and be clear about why the sample still fails.

for a principal

Decide whether a repeat attempt belongs in the plan at all, and make the absence of a retry element an explicit, documented position rather than a surprise.

## What the property really is JMeter's default HTTP implementation in 6.0.0 is `HttpClient4`. When it builds its client it wires in Apache HttpClient's `StandardHttpRequestRetryHandler`, constructed from two JMeter properties: - `httpclient4.retrycount` — how many retries to attempt, default `0`; - `httpclient4.request_sent_retry_enabled` — whether a request that has already been sent may be retried, default `false`. The component reference is explicit about the default: retry is set to `0` for both the HttpClient4 and the Java implementations, meaning no retry is attempted. Raising it is a one-line property change: ```properties httpclient4.retrycount=3 ``` With the default `request_sent_retry_enabled=false`, retries happen only on idempotent methods. The manual notes the widening switch exists mainly for awkward infrastructure — some load balancers reset connections in ways that make a non-idempotent retry the lesser evil. ## What it covers - A connection that could not be established or that broke while the request was in flight. - Transport-level I/O errors surfaced by the HTTP client during execution. ## What it does not cover - **Any response the server returned.** A `401`, a `500`, a redirect loop — all of these are completed exchanges. The retry handler never sees them. - **An assertion failure.** Assertions run after the sampler in the thread, far outside the HTTP client. Nothing in the client knows the sample was later judged a failure. - **A failed extraction.** Same reason. - **Non-idempotent methods, by default.** A `POST` to a login endpoint is exactly the case the default excludes. So for a login that the server rejects, this property does nothing at all — and that is the misunderstanding worth catching in an interview. ## Two more properties in the same family | Property | Applies to | Default | |---|---|---| | `httpclient4.retrycount` | the HttpClient4 implementation | `0` | | `httpclient4.request_sent_retry_enabled` | whether already-sent requests are retried | `false` | | `http.java.sampler.retries` | the Java HTTP implementation | `0` | ## Where it can and cannot be set The count is read into a `static final` field when the implementation class initialises, and the class logs the value it took at startup. Two consequences follow: 1. It is process-wide. You cannot give the login sampler one retry count and the search sampler another, and you cannot vary it per Thread Group. 2. It has to be in place before sampling starts — a properties file, or a JMeter property supplied on the command line. Changing it mid-run is not a thing. In a distributed run this is a per-JVM setting, so every engine needs it, not just the controller. ## The bigger point: JMeter ships no retry element There is no Retry Controller, no “retry on failure” checkbox on a sampler, and no built-in pass-on-retry reporting. A repeat attempt has to be constructed out of the ordinary building blocks — a loop with a condition, plus the bookkeeping for what a second attempt means. It is legitimate to say so plainly in an interview: the honest answer to “how does JMeter retry a failed request?” is that at the plan level it does not, and the only retry it ships is the transport-level one described here. Whether a run *should* retry at all, and how a pass-on-retry ought to be reported, are workload and reporting questions rather than JMeter ones. What belongs here is knowing which of the two you are actually reaching for when you set the property.

  • A colleague sets httpclient4.retrycount=3 to stop a failing login POST from failing the run. What changes?
    Nothing useful. The server answered the request, so no transport error occurred, and a POST is not idempotent, so the default handler would not retry it anyway. The sample still fails and whatever error action the plan carries still fires.
  • Can you give one sampler a higher retry count than the rest of the plan?
    No. The count is read once into a static field when the HTTP implementation initialises, so it applies to every HttpClient4 sampler in that JVM. Per-sampler behaviour would have to be built as an explicit loop in the plan instead.

saying these in an interview costs you the question

  • Thinking it retries a 500 or a 401 response
  • Expecting it to re-run a sampler an assertion failed
  • Assuming a POST is retried under the default settings
  • Believing the count can be set per sampler
  • Claiming JMeter ships a Retry Controller