Eager Quarkus components initialization for good response times of first request after startup

[SpaceFox]

Hi everyone!

As far as I understand, Quarkus and all its modules (OIDC handling, Panache…) are designed for lazy initialisation. This has a lot of advantages but leads to slow "first access" (very first request can take more than a second; first access to any endpoint is way slower than consecutive ones).

I have a case in where all my requests must responds quick, event after a container restart.

I have seen I can use eager instantiation of beans. This works for my beans, but actually most of time spent in initialisation are from Quarkus dependencies (in order: vert.x/http stuff, OIDC, Panache/Hibernate). I tried to add these dependencies in a @Startup method, but this look dirty and is inefficient as I don’t know which beans to create to have a correct initialisation of these dependencies.

The best I have found for now is to add a HTTP call to some actual endpoints on first health-check call. In this case, the first HC call initialise everything and only when it’s done, the container is flagged as "ready".

Do you see a better way to achieve the goal "the first call on a 'ready' Quarkus container must be as reactive as all other ones"?

Thank you in advance!

[mikethecalamity]

@gsmet Any thoughts on this? It's definitely still a problem in 3.34/3.35, I've seen it with Hibernate's EntityManager.

[cescoffier]

In general, we want to avoid lazy initialization. It does not mean we prevent it. However, if you see any Quarkus components that do this, please raise an issue. We need to see if we can improve it and move parts of the initialization (when possible) to build time. Of course, for things that "connect" to remote infrastructure, this may not be possible.

[SpaceFox]

I’m surprised by this answer, for me the lazy initialisation for internal Quarkus proxies (@ApplicationScoped etc., I don’t know the internal Quarkus name) were done on purpose, same for OIDC handling or Panache. From my point of view it was done as is to allow a very fast startup and avoid to use resources on unused components.

[dmlloyd]

For cases like these (assuming that it is accurate), I wonder if we can have an eager post-startup stage which initializes these things right away after the server is reported "up". That might be a good middle ground.

[dmlloyd]

One thing to consider is that the JVM will always be lazily initializing some things, like lambdas, dynamic constants, certain kinds of classes, etc. Compiling to native is the only way I know of to eagerly initialize everything.

[RinZ27]

The lazy-init pattern in Quarkus (Vert.x, OIDC, Hibernate) is intentional, but there are a few solid options depending on how much control you need.

Option 1: @Startup + explicit bean touch (cleaner than it sounds)

For Hibernate specifically, injecting EntityManagerFactory or SessionFactory in a @Startup bean forces the full schema validation + connection pool initialization at boot:

@ApplicationScoped
public class EagerInitializer {

    @Inject
    EntityManagerFactory emf; // forces Hibernate init

    @Inject
    OidcClient oidcClient;    // forces OIDC token endpoint discovery

    void onStart(@Observes StartupEvent ev) {
        // just touching the injected beans is enough to trigger init
        emf.isOpen();
    }
}

Option 2: Kubernetes readiness probe + warmup endpoint

Your current approach (HTTP call during health check) is actually the most pragmatic for production and widely used. The trick is to make the /q/health/ready check itself trigger the expensive paths:

@Readiness
@ApplicationScoped
public class WarmupHealthCheck implements HealthCheck {

    @Inject PanacheRepository<MyEntity> repo;

    @Override
    public HealthCheckResponse call() {
        // one lightweight query forces Hibernate connection pool warmup
        repo.count();
        return HealthCheckResponse.up("warmup");
    }
}

Once this returns UP, k8s starts routing traffic — at which point Hibernate is already warmed up.

Option 3: Native image

As @dmlloyd mentioned, native compilation (-Dquarkus.package.type=native) eliminates almost all JVM lazy-init. First-request latency drops dramatically because class loading and JIT overhead are gone entirely. Worth the build time cost if cold-start SLA is strict.

Bottom line: for JVM mode, combining @Startup injection + a warmup health check is the most reliable approach. For strict latency SLAs, native is the definitive fix.