Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Get started with Spring and Spring Boot, through the Learn Spring course:
>> LEARN SPRINGExplore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely β and automatically β with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. Thatβs where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions β one for newcomers and one for experienced users. Youβll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
1. Introduction
In this tutorial, weβll explore why we may see DataBufferLimitException in a Spring Webflux application. Weβll then take a look at the various ways we can resolve the same.
2. Understanding the Problem
Letβs understand the problem first before jumping to the solution.
2.1. Whatβs DataBufferLimitException?
Spring WebFlux limits buffering of data in-memory in codec to avoid application memory issues. By default, this is configured to 262,144 bytes. When this isnβt enough for our use case, weβll end up with the DataBufferLimitException.
2.2. Whatβs a Codec?
The spring-web and spring-core modules provide support for serializing and deserializing byte content to and from higher-level objects through non-blocking I/O with reactive stream back pressure. Codecs offer an alternative to Java serialization. One advantage is that, typically, objects need not implement Serializable.
3. Server Side
Letβs first look at how DataBufferLimitException plays out from a server perspective.
3.1. Reproducing the Issue
Letβs try to send a JSON payload of size 390 KB to our Spring Webflux server application to create the exception. Weβll use the curl command to send a POST request to our server:
curl --location --request POST 'http://localhost:8080/1.0/process' \
--header 'Content-Type: application/json' \
--data-binary '@/tmp/390KB.json'
As we can see, the DataBufferLimitException is thrown:
org.springframework.core.io.buffer.DataBufferLimitException: Exceeded limit on max bytes to buffer : 262144
at org.springframework.core.io.buffer.LimitedDataBufferList.raiseLimitException(LimitedDataBufferList.java:99) ~[spring-core-5.3.23.jar:5.3.23]
Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:
Error has been observed at the following site(s):
*__checkpoint β’ HTTP POST "/1.0/process" [ExceptionHandlingWebHandler]
3.2. Solution
We can use the WebFluxConfigurer interface to configure the same thresholds. To do this, weβll add a new configuration class, WebFluxConfiguration:
@Configuration
public class WebFluxConfiguration implements WebFluxConfigurer {
@Override
public void configureHttpMessageCodecs(ServerCodecConfigurer configurer) {
configurer.defaultCodecs().maxInMemorySize(500 * 1024);
}
}
We also need to update our application properties:
spring:
codec:
max-in-memory-size: 500KB
4. Client Side
Letβs now switch gears to look at the client-side behavior.
4.1. Reproducing the Issue
Weβll try to reproduce the same behavior with Webfluxβs WebClient. Letβs create a handler that calls the server with a payload of 390 KB:
public Mono<Users> fetch() {
return webClient
.post()
.uri("/1.0/process")
.body(BodyInserters.fromPublisher(readRequestBody(), Users.class))
.exchangeToMono(clientResponse -> clientResponse.bodyToMono(Users.class));
}
We see again that the same exception is thrown but this time due to the webClient trying to send a larger payload than allowed:
org.springframework.core.io.buffer.DataBufferLimitException: Exceeded limit on max bytes to buffer : 262144
at org.springframework.core.io.buffer.LimitedDataBufferList.raiseLimitException(LimitedDataBufferList.java:99) ~[spring-core-5.3.23.jar:5.3.23]
Suppressed: reactor.core.publisher.FluxOnAssembly$OnAssemblyException:
Error has been observed at the following site(s):
*__checkpoint β’ Body from POST http://localhost:8080/1.0/process [DefaultClientResponse]
*__checkpoint β’ Handler com.baeldung.spring.reactive.springreactiveexceptions.handler.TriggerHandler@428eedd9 [DispatcherHandler]
*__checkpoint β’ HTTP POST "/1.0/trigger" [ExceptionHandlingWebHandler]
4.2. Solution
Weβve also got a programmatic way to configure the web clients to achieve this goal. Letβs create a WebClient with the following configuration:
@Bean("progWebClient")
public WebClient getProgSelfWebClient() {
return WebClient
.builder()
.baseUrl(host)
.exchangeStrategies(ExchangeStrategies
.builder()
.codecs(codecs -> codecs
.defaultCodecs()
.maxInMemorySize(500 * 1024))
.build())
.build();
}
We also need to update our application properties:
spring:
codec:
max-in-memory-size: 500KB
And with that, we should now be able to send payloads larger than 500 KB from our application. Itβs worth noting that this configuration gets applied to the entire application, which means to all web clients and the server itself.
Hence, if we want to configure this limit only for specific web clients, then this wonβt be an ideal solution. Additionally, there is a caveat with this approach. The builder used to create the WebClients must be auto-wired by Spring like the below:
@Bean("webClient")
public WebClient getSelfWebClient(WebClient.Builder builder) {
return builder.baseUrl(host).build();
}
5. Conclusion
In this article, we understood what DataBufferLimitException is and looked at how to fix them on both the server and client sides. We looked at two approaches for both, based on properties configuration and programmatically. We hope this exception wonβt be a trouble for you anymore.
