Do Quarkus security components and filters run on virtual threads with @RunOnVirtualThread-marked route resources?

[lloydmeta]

Context

• Quarkus version: 3.23.2
• REST extension: Using io.quarkus:quarkus-rest and io.quarkus:quarkus-rest-jackson
• Virtual threads: Running with the default virtual thread scheduler on Java 24. All JAX-RS endpoint classes are annotated with @RunOnVirtualThread.

Observations

Everything seems to be running on virtual threads in my application (stripped down version at https://github.com/lloydmeta/quarkus-vthread-pre-routes), including the security-related components. For example, I've logged the thread names in my custom authentication mechanism, identity provider, and request/response filters. The logs consistently show the quarkus-virtual-thread-* thread name for these components:

2025-06-06 11:45:12,345 INFO  [com.beachape.example.auth.MyAuthMechanism] (quarkus-virtual-thread-0) Starting authentication for request...
2025-06-06 11:45:12,678 INFO  [com.beachape.example.auth.MyIdentityProvider] (quarkus-virtual-thread-0) Validating credentials for user: alice
2025-06-06 11:45:12,901 INFO  [com.beachape.example.filters.AuditFilter] (quarkus-virtual-thread-0) Request from 127.0.0.1 -> GET /api/resource
2025-06-06 11:45:13,012 INFO  [com.beachape.example.filters.AuditFilter] (quarkus-virtual-thread-0) Response status: 200 OK

As shown above, my custom HttpAuthenticationMechanism (MyAuthMechanism), the corresponding IdentityProvider, and a filter (AuditFilter implementing ContainerRequestFilter/ContainerResponseFilter) all appear to execute on quarkus-virtual-thread-0 This suggests that when the resource class is annotated with @RunOnVirtualThread, the Quarkus framework is offloading not just the resource methods but also these security interceptors and filters to a virtual thread.

Research

I looked through some Quarkus PRs, documentation and guides but didn't find an explicit confirmation about the thread context for security components under virtual threads. The official Virtual Threads guide explains how @RunOnVirtualThread offloads the endpoint handler execution to a virtual thread, allowing blocking operations without tying up the event loop thread. However, it doesn't explicitly mention whether things like the HttpAuthenticationMechanism, IdentityProvider, or JAX-RS request/response filters are also executed on that virtual thread or still on the standard Vert.x event loop/worker threads.

Given that I'm using Quarkus REST (FKA RESTEasy reactive), I expect that virtual thread offloading should apply (IIUC the classic RESTEasy stack doesn't fully support virtual threads). The fact that my logs show these components running on quarkus-virtual-thread is encouraging. However, I want to be sure this is reliable and by design, not just an accidental side-effect.

Question

Is the observed behavior expected? In other words, when using @RunOnVirtualThread on my endpoints' class, should I expect that the entire request processing pipeline, including custom HttpAuthenticationMechanism/IdentityProvider execution and any ContainerRequestFilter/ContainerResponseFilter, runs on a virtual thread?

If so, are there any caveats or best practices I should be aware of to ensure this always holds true? For example:

• Do I need to use any specific annotations or interfaces (like reactive-specific filter interfaces) to guarantee those components run on virtual threads?
• Are there known limitations or scenarios where some part of the security/auth processing might still run on a standard thread (event loop or worker) despite @RunOnVirtualThread?

I appreciate any clarification. I want to make sure I'm doing this correctly and not missing a subtle detail about how Quarkus handles virtual threads in the security/filter pipeline. Thanks in advance!

[quarkus-bot[bot]]

/cc @cescoffier (virtual-threads), @ozangunalp (virtual-threads), @sberyozkin (security)

[sberyozkin]

@lloydmeta It does look like that the Vert.x handler which manages the offloading to the virtual thread is running early, before various Quarkus HTTP aware components run, such as Quarkus security ones, or JAX-RS filters.

I think it makes sense, perhaps you can try to execute a blocking operation in the custom IdentityProvider on the current virtual thread, without using the provided authentication context which is typically used for executing blocking operations

[sberyozkin]

@lloydmeta Sure, so if you can confirm the blocking operation can actually be run directly on the virtual thread without using the context, then we can advise users about it

[sberyozkin]

We can probably add a test to verify

[lloydmeta]

@lloydmeta Sure, so if you can confirm the blocking operation can actually be run directly on the virtual thread without using the context, then we can advise users about it

Not sure what you had in mind, and since I don't actually have a real blocking op yet (will add it later), I added a simple blocking sleep:

    try {
      Thread.sleep(Duration.ofSeconds(5));
    } catch (InterruptedException e) {
      LOGGER.error("Interrupted", e);
    }

And after kicking off a loop'ed curl, it seems nothing within Quarkus is complaining (at least in dev mode), and I'm getting responses from my endpoint that I would expect. The thread numbers did get really high, quarkus-virtual-thread-6134 or so, (it's a fairly tight loop; while true; do with a small sleep and a curl that runs in the background w/ &) but I don't imagine that's problematic given my understanding of virtual threads.

[sberyozkin]

@lloydmeta Yes, this is exactly what I meant, emulating the blocking operation was equally good for a test, thanks

[lloydmeta]

Cheers. I created a stripped down version of my project at https://github.com/lloydmeta/quarkus-vthread-pre-routes