For more information about the tags available, please visit the Docker Hub repository.

SonarQube Report (cloud)

For more information, visit the SonarCloud Dashboard.

Introduction

This project is a Quarkus application that demonstrates how to create a system capable of tracking incoming and outgoing JAX-RS requests from the application across various storage channels, such as a MongoDB database, SQL, or an AMQP broker, by leveraging Quarkus's Event Bus.

Figure 1 - Quarkus Application Flow

If you want to learn more about Quarkus, visit the official website quarkus.io. Below are the instructions for running the application in development mode and creating a native executable.

High-Performance Tracing Architecture

Since version 1.3.1 the JAX-RS filter has been redesigned with a capture-only + external dispatcher pattern to eliminate any impact on HTTP throughput.

How it works

Figure 2 - High-Performance Tracing Architecture

Configuration properties

Filter execution order

@ServerRequestFilter and @ServerResponseFilter (from RESTEasy Reactive) participate in the standard JAX-RS priority chain alongside any @Provider-based filters:

Thread model - blocking vs reactive endpoints:

• Blocking endpoints (classic JAX-RS, Response return type): the filter runs on a worker thread (executor-thread-*). Body reading is performed directly in blocking mode.
• Reactive endpoints (Uni<Response>, Multi<T>): the filter runs on the I/O event loop thread (vert.x-eventloop-thread-*). Body reading is automatically delegated to a Vert.x worker thread via Vertx#executeBlocking() to avoid blocking the event loop.

Note: @NonBlocking must not be placed on @ServerRequestFilter/@ServerResponseFilter methods. Quarkus rejects it at build time (ExecutionModelAnnotationsProcessor throws IllegalStateException). The Uni<Void> return type is the only correct non-blocking signal.

Reactive endpoint support

The filter handles both blocking and reactive JAX-RS endpoints transparently via the readBodyAsync() method, which applies a two-level adaptive strategy:

Why not Vertx.currentContext().isEventLoopContext()? In Vert.x 4.x the Vert.x context is propagated to worker threads (executor-thread-*) keeping the EventLoopContext type - so isEventLoopContext() returns true even on physical blocking threads, making it an unreliable discriminator. The physical thread name (Thread.currentThread().getName()) is the only reliable check.

Reactive echo endpoint (POST /api/rest/echo/reactive)

The project exposes a dedicated reactive endpoint that returns Uni<Response> and runs on the I/O event loop thread. It can be used to verify filter behavior with non-blocking endpoints:

# Call the reactive echo endpoint (runs on vert.x-eventloop-thread-*)
curl -v --http2 \
  -H "Content-Type: application/json" \
  -d '{"message": "Test di tracking richiesta JAX