DEV Community: Renato Fialho

One Load per Key: Collapsing Duplicate Lookups with Spring Boot's Cache and Caffeine

Renato Fialho — Fri, 23 Oct 2026 21:01:53 +0000

Rule engines, aggregators and validation pipelines share a hidden cost. Many independent components ask the same downstream question, with the same key, at the same moment. Each component is correct on its own; together they multiply the load on whatever sits behind them.

This article shows how to collapse those calls into a single load using Spring's cache abstraction backed by Caffeine. It also covers what tends to bite afterwards: cached empty results, metrics that change meaning, and tests that pass for the wrong reason.

The scenario

Take a promotion eligibility service. To decide whether a product qualifies for a promotion, it evaluates about 20 rules in parallel: in stock, price above a threshold, seller in good standing, category not excluded, and so on.

List<CompletableFuture<Boolean>> results = rules.stream()
        .map(rule -> CompletableFuture.supplyAsync(() -> rule.test(productId), executor))
        .toList();

Each rule depends on a small, focused service:

@Component
class InStockRule implements Rule {

    private final StockService stockService;

    @Override
    public boolean test(String productId) {
        return stockService.isInStock(productId);
    }
}

@Service
class StockService {

    private final ProductCatalogue catalogue;

    boolean isInStock(String productId) {
        return catalogue.findProduct(productId)
                .map(product -> product.stock() > 0)
                .orElse(false);
    }
}

PricingService, SellerService and CategoryService look the same: each one reads a different field from the same Product, which comes from one place:

@Service
public class ProductCatalogue {

    // Reads from a shared cache (Redis, DynamoDB, ...), falls back to the catalogue API on a miss.
    public Optional<Product> findProduct(String productId) {
        return store.get(productId).or(() -> fetchAndStore(productId));
    }
}

The design is clean: every rule is small, testable and independent. But one evaluation of one product calls findProduct about 20 times:

Warm path: 20 reads from the shared cache, plus 20 deserialisations of the same object.
Cold path: all 20 calls miss at the same time, so the catalogue API gets 20 concurrent requests for the same product. That's a cache stampede, and it hits hardest when the downstream system is already struggling.

The calls don't need 20 answers. They need one.

Why not request scope?

The first idea is usually a request-scoped cache: memoise the response for the lifetime of the HTTP request. That works less well than it sounds:

Thread hopping. The rules run on executor threads. Request attributes are bound to the request thread, so request-scoped beans only work if you propagate the context to every executor (for example with a TaskDecorator).
No request at all. Queue consumers, Kafka listeners and scheduled jobs have no HTTP request. A @RequestScope bean there fails with No thread-bound request found.

A short-lived, in-process cache gives the same effect on every entry point. The price is bounded staleness, and with a short enough TTL that price is negligible.

Setup

Dependencies

spring-boot-starter-cache brings Spring's cache abstraction, but not Caffeine. Add both. Spring Boot manages the Caffeine version.

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
</dependency>

implementation("org.springframework.boot:spring-boot-starter-cache")
implementation("com.github.ben-manes.caffeine:caffeine")

Enable caching

@SpringBootApplication
@EnableCaching
public class Application { }

Configure the cache

spring:
  cache:
    type: caffeine
    cache-names: products
    caffeine:
      spec: maximumSize=10000,expireAfterWrite=30s,recordStats

Each line matters:

type: caffeine makes the application fail at startup if Caffeine is missing. Without it, Spring Boot silently falls back to ConcurrentMapCacheManager. That cache ignores caffeine.spec, so it has no size limit and entries never expire: unbounded memory and unbounded staleness, a worse problem than the one you set out to fix. Dependencies move around, so don't rely on Caffeine always being on the classpath.
cache-names creates the listed caches at startup and turns off dynamic creation: a @Cacheable that uses an unlisted name fails at runtime. It's also what lets Spring Boot register Micrometer metrics for the cache, because only caches that exist at startup are bound.
spec: maximumSize caps memory, expireAfterWrite caps staleness, and recordStats turns on the hit/miss statistics behind the metrics.

The annotation

@Cacheable(cacheNames = "products", key = "#productId", sync = true)
public Optional<Product> findProduct(String productId) {
    return store.get(productId).or(() -> fetchAndStore(productId));
}

Two attributes do most of the work here.

sync = true is the difference between caching and collapsing. Without it, Spring checks the cache, misses, calls the method and stores the result. When 20 threads miss at the same moment, all 20 call the method. With sync = true, Spring hands the load to Caffeine's atomic get(key, loader): the first thread runs the method, and the other 19 wait for its result.

key = "#productId" makes the key explicit. The default key generator uses the bare argument for single-argument methods, but the moment someone adds a second parameter, the key changes shape and any matching @CacheEvict silently stops working. Referring to parameters by name needs the -parameters compiler flag (Spring Boot's build plugins enable it); otherwise use #p0.

Evicting works the same way:

@CacheEvict(cacheNames = "products", key = "#productId")
public void evict(String productId) { }

@CacheEvict(cacheNames = "products", allEntries = true)
public void evictAll() { }

A classic mistake: @CacheEvict("products") on a method with no arguments evicts the key SimpleKey.EMPTY, which clears nothing. Use allEntries = true to clear the whole cache.

What will surprise you

1. Empty results are cached too

Spring unwraps Optional: present values are stored as the value, and empty ones are stored as null. CaffeineCacheManager allows null values by default, so "product not found" is memoised for the full TTL.

This is often what you want: without it, a missing product is looked up again by every one of the 20 callers. But decide it deliberately. The usual escape hatch, unless = "#result == null", isn't allowed together with sync = true. If you can't accept caching empty results, you'll need a different shape, for example throwing a not-found exception (exceptions are never cached) or using the Cache API directly.

2. Failures are not shared

Exceptions aren't cached. That's good: a transient failure doesn't stick for the next 30 seconds. But it also means that when the load fails, the waiting callers don't get the error. They retry the load one after another. Under a sustained outage, put a circuit breaker or a stale-fallback strategy inside the loaded method. Don't count on the cache to absorb the failures.

3. Every caller gets the same instance

Before the cache, each caller got its own freshly deserialised copy. Now all callers within the TTL share one object, across threads. If anything modifies it, you have a data race between components that don't know about each other. Prefer immutable types (records, or immutable generated classes). If you can't, say so in a comment on the cached method.

4. Self-invocation bypasses the cache

@Cacheable works through a Spring proxy. A call from inside the same class (this.findProduct(...)) skips the proxy and the cache. Check that every hot caller goes through the bean.

5. The cache is per instance

Each pod or instance has its own cache. An eviction endpoint only clears the instance that received the request; the others keep serving the old value until the TTL expires. That's acceptable when the TTL is short. Write it down for whoever operates the endpoint.

6. Your existing metrics change meaning

Any counter incremented inside the cached method (misses on the shared cache, remote calls, fallbacks) now only fires on in-memory misses. On the day you deploy, dashboards show a sudden drop that looks like an outage or a miracle. It's neither. Warn people before the deploy, and add the cache's own metrics, which recordStats exposes:

cache.gets{cache="products", result="hit"|"miss"}
cache.puts
cache.evictions
cache.size

7. Pick the TTL for the unit of work

The goal is to collapse the calls within one unit of work, not to build a long-lived performance cache. So the TTL needs to be long enough to cover one evaluation including slow paths (retries and their backoff), and short enough that the extra staleness is negligible compared with how fresh the data behind it is anyway. Seconds to tens of seconds is usually right. If you want a longer TTL, that's a different cache, and it needs its own invalidation design.

8. Virtual threads on JDK 21–23

With sync = true, the load runs inside Caffeine's atomic compute, which holds a synchronized lock. On JDK 21–23, a virtual thread that blocks on I/O inside synchronized pins its carrier thread. Since carrier threads are few (one per core by default), many concurrent cold loads can starve the scheduler. JDK 24 fixed this (JEP 491). On older JDKs, load-test the cold path with -Djdk.tracePinnedThreads=full.

Testing it

Prove that concurrent misses collapse

A naive test fires 20 calls and checks that the loader ran once. It usually passes even without sync = true: the stubbed load returns instantly, so the calls run one after another and the first one fills the cache before the second arrives. The test has to keep callers inside the loader until all of them have arrived:

@SpringJUnitConfig(ProductCatalogueCachingTest.Config.class)
class ProductCatalogueCachingTest {

    private static final int CALLERS = 20;

    @Autowired
    ProductCatalogue catalogue;
    @MockitoBean
    ProductStore store;

    @Test
    void concurrentMissesLoadOnce() throws Exception {
        var allCallersLoading = new CountDownLatch(CALLERS);
        var release = new CountDownLatch(1);
        // Every caller that reaches the loader waits here, so without sync = true all of them would load.
        when(store.get("p-1")).thenAnswer(invocation -> {
            allCallersLoading.countDown();
            release.await(5, TimeUnit.SECONDS);
            return Optional.of(new Product("p-1", 3));
        });

        try (var executor = Executors.newFixedThreadPool(CALLERS)) {
            var futures = IntStream.range(0, CALLERS)
                    .mapToObj(i -> executor.submit(() -> catalogue.findProduct("p-1")))
                    .toList();
            allCallersLoading.await(500, TimeUnit.MILLISECONDS);
            release.countDown();
            for (var future : futures) {
                assertThat(future.get(5, TimeUnit.SECONDS)).isPresent();
            }
        }
        verify(store, times(1)).get("p-1");
    }

    @Configuration
    @EnableCaching
    static class Config {

        @Bean
        CacheManager cacheManager() {
            return new CaffeineCacheManager("products");
        }

        @Bean
        ProductCatalogue catalogue(ProductStore store) {
            return new ProductCatalogue(store);
        }
    }
}

With sync = true, the first caller enters the loader and the other 19 wait in Caffeine, so get runs once. Without it, all 20 enter the loader and the test fails with Wanted 1 time, but was 20 times. Remove sync = true once to see that failure: a test you've never seen fail hasn't proven anything.

Prove that the shipped configuration is the one you think

The test above builds its own CaffeineCacheManager, so it never touches application.yml. A typo in cache-names, or a missing type, would only show up in production. ApplicationContextRunner can load the real configuration file with only the cache auto-configuration:

@Test
void applicationConfigurationCreatesBoundedCaffeineCache() {
    new ApplicationContextRunner()
            .withInitializer(new ConfigDataApplicationContextInitializer())
            .withConfiguration(AutoConfigurations.of(CacheAutoConfiguration.class))
            .withUserConfiguration(CachingEnabled.class)
            .run(context -> {
                var manager = context.getBean(CacheManager.class);
                assertThat(manager).isInstanceOf(CaffeineCacheManager.class);

                var cache = (com.github.benmanes.caffeine.cache.Cache<?, ?>)
                        manager.getCache("products").getNativeCache();
                assertThat(cache.policy().eviction().orElseThrow().getMaximum()).isEqualTo(10_000);
                assertThat(cache.policy().expireAfterWrite().orElseThrow().getExpiresAfter())
                        .isEqualTo(Duration.ofSeconds(30));
            });
}

@Configuration
@EnableCaching
static class CachingEnabled { }

CacheAutoConfiguration lives in org.springframework.boot.cache.autoconfigure in Spring Boot 4, and in org.springframework.boot.autoconfigure.cache in Spring Boot 3.

Also add one test each for eviction (evict, call again, check the loader ran twice) and for whichever empty-result behaviour you chose.

Checklist

[ ] spring-boot-starter-cache and caffeine declared, @EnableCaching on
[ ] spring.cache.type: caffeine so a missing Caffeine fails at startup
[ ] cache-names declared (and new names added there)
[ ] maximumSize, expireAfterWrite and recordStats in the spec
[ ] @Cacheable(sync = true) with an explicit key
[ ] @CacheEvict uses the same key; clear-all uses allEntries = true
[ ] Empty-result caching decided and tested
[ ] Cached return type immutable, or documented as shared
[ ] No self-invocation on hot paths
[ ] Dashboard owners warned about counters inside the cached method
[ ] Concurrency test that fails without sync = true
[ ] Configuration test against the real application.yml
[ ] On JDK 21–23 with virtual threads: cold path load-tested for pinning

Wrapping up

The change itself is a dependency, a few lines of YAML and one annotation. Most of the value is in the rest: deciding what gets cached (including "not found"), making the configuration fail loudly instead of degrading silently, warning the people who read the metrics, and writing tests that actually fail when the behaviour breaks. Get those right, and twenty components asking the same question cost the same as one.

Java 19 and the new Virtual Threads

Renato Fialho — Tue, 27 Sep 2022 13:59:21 +0000

This post can be read here as well.

What?

Java 19 is coming, and with this new version of Java, it brings an amazing new feature, virtual threads.

This update comes to reduce the effort of writing, maintaining, and observing high-throughput, concurrent applications.

This is part of the Project Loom, a project that aims to bring a new concurrency model to java, but preserving the same simple abstraction to the developers.

Don't worry, you will still be able to use the platform threads.

How?

Currently, those implementations are on preview mode, so you must provide the --enable-preview flag to the JVM.

If you are an IntelliJ user, you can tell IntelliJ to use this flag by going into the Open Module Settings -> Project -> Language Level and choose the Java 19 (Preview).

    // Declare a runnable that will print the information about the current thread
    Runnable printThread = () -> System.out.println(Thread.currentThread());

    // Declare a virtual thread
    var virtualThread = Thread.ofVirtual()
        .start(printThread);

    // Declare a platform thread
    var platformThread = Thread.ofPlatform()
        .start(printThread);

The output will be:

    VirtualThread[#22]/runnable@ForkJoinPool-1-worker-1
    Thread[#24,Thread-0,5,main]

Now you see that we have a virtual thread executing on a worker thread of the Fork-Join pool, and another platform thread running on the main process.

Seamless integration between platform and virtual threads

Synchronized blocks will work transparent in between virtual and platform threads, as it is shown in this example.

class VirtualThreads {

    public static void main(String[] args) {
        var c = new VirtualThreads();
        c.start();
    }

    public void start() {
        var virtualThread = Thread.ofVirtual();
        var platformThread = Thread.ofPlatform();

        virtualThread.start(() -> {
            System.out.println(Thread.currentThread() + " running command A");
            synchronized(this) {
                try {
                    this.wait();
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
            }
            System.out.println(Thread.currentThread() + " running command C");
        });

        platformThread.start(() -> {
            System.out.println(Thread.currentThread() + " running command B");
            synchronized(this) {
                this.notifyAll();
            }
        });
    }
}

The output will be:

    VirtualThread[#22]/runnable@ForkJoinPool-1-worker-1 running command A
    Thread[#24,Thread-0,5,main] running command B
    VirtualThread[#22]/runnable@ForkJoinPool-1-worker-1 running command C

Loom and Java in general are prominently devoted to building web applications. Obviously, Java is used in many other areas, and the ideas introduced by Loom may well be useful in these applications.

It’s easy to see how massively increasing thread efficiency, and dramatically reducing the resource requirements for handling multiple competing needs, will result in greater throughput for servers. Better handling of requests and responses is a bottom-line win for a whole universe of existing and to-be-built Java applications.

Reference

Learn SOLID design principles using Java

Renato Fialho — Mon, 26 Sep 2022 15:40:04 +0000

This post can be seen here as well.

The main idea from this article is to show the SOLID design principles and provide examples of implementations of those principles using Java as the main language.

What is SOLID?

S.O.L.I.D stands for:

Single Responsibility Principle

Open Closed Principle

Liskov Substitution Principle

Interface Segregation Principle

Dependency Inversion Principle

Design principles in general helps us to write better software. And also improves the developer experience of the developers that share the same codebase with you.

Single Responsibility Principle

A class should have only one responsibility.

It helps into onboarding new members into the code, as well to test, maintain and grow our codebase.

Example

Imagine that you have a UserService that is like this:

class UserService {

    public void createUser() {
        // Create our user here
    }

    public User findById(UUID id) {
        // Return our user
    }

    private void sendAppNotification() {
        // Send an app notification
    }

    private void sendEmail() {
        // Send an email
    }
}

What happens if the requirements of this class change? What if now we must send a tex now we have to send an App Notification via push or SMS?

Then, we must separate the concerns and responsability by creating a NotificationService that will handle all of our communications.

class UserService {

    private final NotificationService notificationService;

    public void createUser() {
        // Create our user here
    }

    public User findById(UUID id) {
        // Return our user
    }
}

class NotificationService {
    public void sendSms() {
        // Send SMS
    }

    public void sendPushNotification() {
        // Send push
    }

    public void sendEmail() {
        // Send email
    }
}

Even though it can have better approaches here, the idea is to separate concerns, the other solutions to solve this kind of problem is a different topic.

Open Closed Principle

Software entities (classes, modules, functions, etc.) should be opened to extension but closed to modification.

Example

Think that we have an CoffeeApp class

public class CoffeeApp {
    public void brewSimpleCoffee() {
        // Put water
        // Put coffee powder
    }

    public void brewPremiumCoffee() {
        // Get the bean
        // Grind the bean
        // Put water
    }
}

Imagine that everytime our system needs to support a new type of coffee, we must change the Machine in order to add a new type.

Lets use of simple abstraction and polymorphism to improve this

public class CoffeeApp {
    public static void greet(CoffeeMachine coffeeMachine) {
        coffeeMachine.brewCoffee(ESPRESSO);
    }
}

interface CoffeeMachine {
    Coffee brewCoffee(CoffeeSelection selection);
}

public class BasicCoffeeMachine implements CoffeeMachine {
    private BrewingUnit brewingUnit;

    @Override
    public Coffee brewCoffee(CoffeeSelection selection) {
        brewFilterCoffee();
    }

    private brewFilterCoffee() {
        brewingUnit.brew();
    }
}

public class PremiumCoffeeMachine implements CoffeeMachine {
    private Grinder grinder;
    private BrewingUnit brewingUnit;

    @Override
    public Coffee brewCoffee(CoffeeSelection selection) {
    switch(selection) {
        case ESPRESSO:
            return brewEspresso();
        case FILTER_COFFEE:
        default:
            return brewFilterCoffee();
        }
    }

    private brewEspresso() {
        grinder.grind()
        brewingUnit.brew();
    }

    private brewFilterCoffee() {
        brewingUnit.brew();
    }
}

Now that class is opened for extension (ItalianMachine, ColombianMachine, FrenchPressMachine) and closed for modification (won’t have a method with a different logic being added every time a new machine is added to the app).

Liskov Substitution Principle

A class can be replaced by its subclass in all practical usage scenarios, meaning that you should use inheritance only for substitutability.

Example

Using an Animal example

interface Animal {
    void fly();
    void swim();
}

public class Dog implements Animal {
    // A dog can swim
    @Override
    public void swim() {
        // Swim
    }

    // But a dog cannot fly
    @Override
    public void fly() {
        throw new IllegalStateException();
    }
}

public class Hawk implements Animal {
    // A hawk cannot swim
    @Override
    public void swim() {
        throw new IllegalStateException();
    }

    // But a hawk can fly
    @Override
    public void fly() {
       // Fly
    }
}

Even though, both a Dog and a Hawk are animals, we can break up the inheritance to follow up this principle

interface Animal {
    void swim();
}

interface Bird {
    void fly();
}

public class Dog implements Animal {
    // A dog can swim
    @Override
    public void swim() {
        // Swim
    }
}

public class Hawk implements Bird {
    // A hawk can fly
    @Override
    public void fly() {
       // Fly
    }
}

Interface Segregation Principle

A client shouldn’t be forced to implement an interface that it doesn’t use.

Example

Thinking about the last example, even though a Dog can only swim, some Animals can swim and fly.

Isn't easier if we just implement the interfaces like this

interface Swimmer {
    void swim();
}

interface Bird {
    void fly();
}

public class Dog implements Swimmer {
    // A dog can swim
    @Override
    public void swim() {
        // Swim
    }
}

public class Hawk implements Bird {
    // A hawk can fly
    @Override
    public void fly() {
       // Fly
    }
}

public class Duck implements Swimmer, Bird {
    // A duck can fly
    @Override
    public void fly() {
       // Fly
    }

    // A duck can swim
    @Override
    public void swim() {
        // Swim
    }
}

Dependency Inversion Principle

We should invert the classic dependency between higher level modules and lower level modules, by abstracting their interaction.

Example

Let's say we have some implementations over a database

public class PersonService {
    private final PersonRepository personRepository;

    public PersonService(PersonRepository personRepository) {
        this.personRepository = personRepository;
    }
}

interface PersonRepository {
    Person findById(UUID id);
    Person create(UUID id, String name);
}

public class LocalRepository implements PersonRepository {
    private Map<UUID, Person> repository;

    // Implement the methods
}

public class DatabaseRepository implements PersonRepository {
    // Hibernate entity manager to handle the communication towards the Database.
    private EntityManager entityManager;

    // Implement the methods
}

In this way, the high-level PersonService doesn't care if you are using a LocalDatabase for development or a real database for production.

And for example, you can change your Hibernate implementation to another solution without your high-level service knowing what's going on.

In case if you have any questions or suggestions, feel free to send me a message

How did I move my pet project from Spring MVC to Webflux and Spring Native with GraalVM

Renato Fialho — Mon, 27 Jun 2022 23:35:26 +0000

You can read this post as well here

In my spare time last year, I created a pet project that aggregate news from some sources and delivers them to an Android app that I developed using Flutter, but that pet project is a topic for another post.

The backend for this pet project was firstly built using:

Kotlin
Gradle KTS
Spring Boot (Data, MVC, Security, Actuator)
PostgreSQL (Liquibase for migrations)
Deployed on a heroku free tier dyno (Validating the idea)

As I mentioned above, the stack is currently deployed in a Heroku free tier dyno, and that is a must for me to validate the idea for this project without spending tons of money.

The MVP was deployed in heroku using one of their buildpacks for Gradle and everything was working fine with some struggles:

1 - When I was enriching the DB (POSTing more content), the response times increased a little bit.

2 - Since it is a pet project, the dyno running my app sleep sometimes during the day, and the initialization was very slow (Around 14 seconds)

Those problems were already bothering me, and I already saw a couple things about the reactive stack for Spring (Webflux / R2DBC) that could help me handle more requests on a peak load without scaling my infrasctructure.

Usually on my pet projects, I try to implement some new ideas (On this one, I improved my knowledge in Kotlin and learned Dart and Flutter), but I wasn't 100% sure that Webflux and Spring Native were mature enough for being used in this project (Even though is a pet project, there are currently 500+ MAU)

Skipping some time, I went to the We Are Developers Worldwide Conference in Berlin a couple weeks ago, where a lot of talks were showcasing the new Spring Native and the already "known" Spring Webflux.

So then, I gave that stack a try and those are my learnings from it:

First mistakes

Those 2 technologies are somehow "new" and AFAIK, not being used in a lot of production grade environments.

Even the Spring project promises a lot of great improvements on Spring 6 and Spring Boot 3.0 for the GraalVM and Spring Native support.

With that being said, after some time, i realized that my first mistake was jumping into BOTH of the new technologies at the same time.

That created a feeling of not knowing if the issue was because of Webflux or Spring Native (I lost a couple nights of a lot of Stackoverflow and Github Issues trying to resolve the problems).

Then, I'll try to showcase the ones that I took notes and remember, please let me know if you faced other problems and we can spread the knowledge.

Heroku doesn't support Spring Native out of the box. Yet.

By it's nature of the AOT (Ahead of Time) compiler for the GraalVM, the Spring Native build consumes a lot of resources (It is a huge memory hog) and Heroku doesn't support it yet, so instead, you must build the image yourself or in your CI running ./gradlew bootBuildImage , that will use a buildpack to build and generate a Docker image for you with your application.

Then, you just need to tag it with the registry.heroku.com/<your_app_name>/<build> , push and run heroku container:release web -a <your_app_name>.

Heroku has Docker containers support out of the box, so then it is the same as deploying using one of theirs buildpack.

Spring Data Webflux and R2DBC drivers don't support a lot of nice features from relational databases

We know that Spring Webflux wasn't meant to be used with relational database since the JDBC drivers are I/O blocking, but the R2DBC initiative does it's job quite nicely.

Some features, such as the @OneToMany or @ManyToMany or @ManyToOne or @OneToOne are not supported (yet!) , and in order to make some things to work, you must add some annotations that are a little bit different, such as if you need auditing with the @CreatedAt and other annotations , you must add the @EnableR2dbcAuditing annotation.

Well, AFAIK, Quarkus and Micronaut already support some of those features with Native builds, so maybe this is something that Spring Data R2DBC will bring in the near future.

Liquibase is NOT supported. Yet.

My first thought when implementing this project was to literally "copy/paste" most of the code from the project that is currently successfully running.

And the database migration management tool that I was using is Liquibase (Wasn't a must, but instead, a good to have tool).

I started adding the Liquibase dependency and a lot of issues happened when building the native image, I resolved a lot of them but at the end, struggled with the fact that Liquibase currently doesn't support Spring Native with GraalVM out of the box, this is an issue for the future, hopefully when they chose their issue on Github, if you are interested, give a +1 on the thumbs up @ the issue!

Most of the monitoring tools are not available. Yet.

One issue for production grade applications is observability and monitoring, so far, I couldn't find any way to make the Newrelic java agent to work together with the GraalVM and Spring Native builds (So, no APM yet!). But you can still instrument your application using the Metrics provided by the actuator and Micrometer with the interfaces to the best providers in the market (Datadog, Newrelic, Prometheus and others).

You must provide some hints to the GraalVM, and some of them are not 100% clear

I faced an issue when running my application as a native app because the database URL was becoming malformed somehow, then, after a lot of research I found the samples repo from Spring that had a lot of tips to use Spring Native with some specific technologies.

The error that i was facing was an <unresolved> showing up from nowhere in the middle of my database URL:

Caused by: io.r2dbc.postgresql.PostgresqlConnectionFactory$PostgresConnectionException: Cannot connect to localhost/<unresolved>:5432

In my case, in order to use the R2DBC PostgreSQL and Spring Native, i had to add this hint to the GraalVM:

@NativeHint(
        trigger = PostgresqlConnectionFactoryProvider.class,
        types = {
                @TypeHint(types = { Instant[].class, ZonedDateTime[].class, URI[].class }, access = {}),
        }
)

You can have a META-INF/native/reflect-config.json file as well.

Results

Well, now, let's come to the results measured so far:

Before:

Started MyApplicationKt in 13.374 seconds (JVM running for 16.857)

Now:

Started MyApplication in 0.129 seconds (JVM running for 0.132)

I'll try to update this post later with some insights on CPU and Memory consumption, but so far, nothing to complain!

How to create slim docker Java Images using a minimal JRE

Renato Fialho — Thu, 14 Apr 2022 13:56:47 +0000

This can be read as well here

In this post, I will explain how you can create slim docker images by creating customized JREs using jlink and jmods.

Those commands are present on JDKs since Java 9, but actually being mature enough since Java 11, they bring a new way to create your customized JRE with only the modules that you need from Java, and then, creating smaller Docker images to run your Java applications (Mainly focused in Spring Boot applications), saving some good bucks in your Container Repository application (ECR, Artifactory, Docker Hub).

But, how do we start?

Assuming you already have a JDK installed in your machine, if not, i strongly suggest you to use sdkman.io and install Java 17 version (Which is the latest LTS as of the date of this post)

First of all, we need to get the list produced from jdeps based in your jarfile from Spring Boot, for example:

$ jdeps --list-deps --ignore-missing-deps  your-fat-jar.jar
   java.base
   java.logging

Well, that doesn't seems right, huh?

Spring Boot has a strategy by default to generate a fat jar with all the needed dependencies inside of it, and jdeps currently can't get all the dependencies recursively inside the jars from the fat-jar.

So, what you can do is to extract all the contents from the fat-jar and run jdeps against every jar in the lib folder.

Or, you can try with try and error, and see which ClassNotFoundException you will get from each JRE version

But, from some previous experience, we usually need those packages in our minimal JRE:

java.compiler
java.logging
java.sql
java.rmi
java.naming
java.management
java.instrument
java.security.jgss
java.net.http
jdk.httpserver
jdk.naming.dns

But my suggestion is to try yourself and see which packages you will really need in your slim JRE

Creating my Java slim JRE

You can use jlink locally to create your customized JRE, the command is somehow like this:

jlink \
    --module-path "$JAVA_HOME/jmods" \
    --add-modules [the java modules your application needs joined by ,] \
    --verbose \
    --strip-debug \
    --compress 2 \
    --no-header-files \
    --no-man-pages \
    --output /opt/jre-minimal

Explaining each flag:

--module-path <path>              Module path.
                                        If not specified, the JDKs jmods directory
                                        will be used, if it exists. If specified,
                                        but it does not contain the java.base module,
                                        the JDKs jmods directory will be added,
                                        if it exists.

--verbose                         Enable verbose tracing

--strip-debug                     Strip debug information

--compress=<0|1|2>                Enable compression of resources:
                                          Level 0: No compression
                                          Level 1: Constant string sharing
                                          Level 2: ZIP

--no-header-files                 Exclude include header files

--no-man-pages                    Exclude man pages

--output <path>                   Location of output path

You can get those informations as well by running jlinks --help in your command line tool.

But then, how do I create my slim Spring Boot application docker image

Well, take this as an example, as i mentioned, it's using the OpenJDK 17 version (Latest LTS by the time this post was written)

# Build our minimal JRE using jlink

FROM openjdk:17-oraclelinux8 as builder

USER root

RUN jlink \
    --module-path "$JAVA_HOME/jmods" \
    --add-modules java.compiler,java.sql,java.naming,java.management,java.instrument,java.rmi,java.desktop,jdk.internal.vm.compiler.management,java.xml.crypto,java.scripting,java.security.jgss,jdk.httpserver,java.net.http,jdk.naming.dns,jdk.crypto.cryptoki,jdk.unsupported \
    --verbose \
    --strip-debug \
    --compress 2 \
    --no-header-files \
    --no-man-pages \
    --output /opt/jre-minimal

USER app

# Now it is time for us to build our real image on top of an slim version of debian

FROM bitnami/minideb:bullseye

COPY --from=builder /opt/jre-minimal /opt/jre-minimal

ENV JAVA_HOME=/opt/jre-minimal
ENV PATH="$PATH:$JAVA_HOME/bin"

VOLUME /tmp

# Copy the JRE created in the last step into our $JAVA_HOME

# For gradle
# COPY build/libs/app-*.jar app.jar

# For maven
# COPY target/app-*.jar app.jar


ENTRYPOINT ["java","-jar","/app.jar"]

But, how efficient is this?

For example, in a regular spring boot application, it saved 200Mb of storage for every image generated, from 543.03 to 349.98, assuming that you always have 10 versions of your application in your container registry, you can save 2 GB of storage space for each application!

You can check an example in this repo

Handling SIGTERM and SIGKILL on Spring Boot web applications

Renato Fialho — Wed, 08 Dec 2021 00:01:29 +0000

This post was reproduced here as well

When debugging one system recently, I found out that every time that a deploy, downscale, container rotation or k8s updates happened I had a lot of connection errors in the ingress car.

In common on those situations, is that k8s sends a SIGTERM, then have a grace period for the application to handle it gracefully, and after N seconds, it sends a SIGKILL, and that is the end.

At first, being a little bit reluctant that the issue was with Spring Boot or the web server that I run with (Tomcat), I tried to check every possible misbehave from the load balancer, no success.

One example on how this works, but mainly from AWS ECS:

Then, after some digging into the server properties in Spring Boot, we found out that the common behaviour for the web server is to shutdown immediately after receiving a SIGTERM, not waiting for any persistentkeep-alive connections to be properly finished and closed.

And how did I fix this?

So, in order to fix that, you must add a line to your application.properties or application.yml file like this:



    server.shutdown=graceful



server:
    shutdown: graceful

Passing graceful to the server shutdown property allows the web server to support graceful shutdown, allowing active requests time to complete and close any persistent keep-alive connections towards your service.

Oh, and if in any case you ended up here but want to know more how Quarkus handles this, i suggest you to take a look here, because it explains in an easy way how to implement this on Quarkus.