skip to content

What is CodecConfigurer's maxInMemorySize, why does it exist, and how do you change it?

level: middleimportance: must knowfreq 60%

answer

  1. Default 256 KB (262144 bytes)
  2. DataBufferLimitException on overflow
  3. defaultCodecs().maxInMemorySize(bytes)
  4. spring.codec.max-in-memory-size property
  5. Bounds aggregation, not a whole-stream limit

basics

~20 s

It's a limit on how many bytes a codec will buffer in memory when it must read the whole body before parsing. Default is 256 KB. Exceeding it throws DataBufferLimitException. You raise it via CodecConfigurer.defaultCodecs().maxInMemorySize(...).

solid answer

~40 s

Codecs that can't parse incrementally — Jackson for a single value, form data, protobuf, string aggregation — buffer the input body in memory before decoding. maxInMemorySize caps that buffering to protect against OutOfMemory / DoS from huge payloads. The default is 256 KB (262144 bytes). When a body exceeds it, decoding fails with DataBufferLimitException, which WebFlux typically surfaces as 4xx (e.g. payload too large). You set it globally on the server via WebFluxConfigurer.configureHttpMessageCodecs by calling configurer.defaultCodecs().maxInMemorySize(bytes), and on WebClient via .codecs(c -> c.defaultCodecs().maxInMemorySize(bytes)). It applies to all buffering default codecs at once. True streaming cases (a Flux of NDJSON elements) aren't bounded by it because each element is small; the limit is per aggregated buffer, not per whole stream.

code

java · 16 lines
java
// Server-side global change
@Configuration
public class CodecConfig implements WebFluxConfigurer {
    @Override
    public void configureHttpMessageCodecs(ServerCodecConfigurer configurer) {
        configurer.defaultCodecs().maxInMemorySize(1024 * 1024); // 1 MB
    }
}

// WebClient-side
WebClient client = WebClient.builder()
        .codecs(c -> c.defaultCodecs().maxInMemorySize(1024 * 1024))
        .build();

// Boot property equivalent:
//   spring.codec.max-in-memory-size=1MB

go deeper

for a junior

Know there's a 256 KB default buffer limit and that big bodies fail unless you raise it.

for a middle

Explain why buffering codecs need the limit, the DataBufferLimitException, and how to set it on server and WebClient.

for a senior

Distinguish per-aggregation bounding from whole-stream size, and relate it to DoS protection and server-level limits.

for a principal

Discuss sizing tradeoffs, layering codec limits with Netty/proxy body limits, and when to stream vs aggregate to avoid the limit entirely.

## Why the limit exists Some codecs can decode incrementally, but many must see a **complete** unit of input before they can produce an object: - `Jackson2JsonDecoder` decoding a single `Mono<T>` value, - form-data (`FormHttpMessageReader`), - protobuf, - `StringDecoder` when aggregating, - multipart part headers. To produce that object, WebFlux **aggregates** the incoming `DataBuffer`s into one in-memory buffer. Without a cap, a malicious or accidental multi-gigabyte body would be buffered entirely and could exhaust the heap — a denial-of-service vector. `maxInMemorySize` is the guardrail. ## The default and the failure mode The default is **256 KB = 262144 bytes** (since Spring Framework 5.1.11-ish this became the enforced default). When the aggregated bytes exceed the limit, the codec throws **`DataBufferLimitException`** (a subtype of `IllegalStateException`). On the server this generally maps to a client error response; on `WebClient` it propagates to the subscriber as an error signal. ## How to change it **Server (global):** ```java @Override public void configureHttpMessageCodecs(ServerCodecConfigurer configurer) { configurer.defaultCodecs().maxInMemorySize(2 * 1024 * 1024); // 2 MB } ``` **WebClient:** ```java WebClient.builder() .codecs(c -> c.defaultCodecs().maxInMemorySize(5 * 1024 * 1024)) .build(); ``` `defaultCodecs().maxInMemorySize(...)` applies the limit to **all** the buffering default codecs at once — you don't set it per codec. ## Important nuances - **It is not a global request-size limit.** It only bounds what a codec buffers in memory to build one value. A genuinely streamed `Flux` (each NDJSON line decoded and emitted individually) is bounded per element, so a long stream of small elements is fine even though the total exceeds 256 KB. - It is distinct from server-level limits (e.g. Netty's max frame/aggregation settings or a reverse-proxy body limit). For hard request-size enforcement you also configure those. - Raising it trades safety for capacity — size it to your realistic largest single payload, not arbitrarily high. - The Spring Boot property `spring.codec.max-in-memory-size` sets it declaratively for both server and WebClient default codecs. ## Symptom to recognize An error like `org.springframework.core.io.buffer.DataBufferLimitException: Exceeded limit on max bytes to buffer : 262144` almost always means a request/response body was larger than `maxInMemorySize` — the fix is to raise the limit (or stream the body instead of aggregating).

  • You get DataBufferLimitException: Exceeded limit on max bytes to buffer : 262144. What is happening and how do you fix it?
    A body being aggregated by a codec exceeded the 256 KB default maxInMemorySize. Fix by raising maxInMemorySize (via configureHttpMessageCodecs, WebClient .codecs, or spring.codec.max-in-memory-size), or by streaming the payload instead of decoding it as a single value.
  • Does maxInMemorySize cap the total size of a streaming NDJSON response with thousands of elements?
    No. It bounds the buffer used to decode a single aggregated value. In true streaming each element is decoded independently, so a long stream of small elements is fine even if the cumulative bytes far exceed the limit.

saying these in an interview costs you the question

  • Saying the default is unlimited
  • Claiming maxInMemorySize is a hard total request-size limit for all requests
  • Thinking it must be set per codec rather than once on defaultCodecs()
  • Confusing DataBufferLimitException with a Netty/proxy-level limit

context

resolving links…