REST client message metadata that can be intercepted in ClientRequestFilter within&outside vertX bootstrap

[lmartella1]

Hello,
in my Quarkus application, which makes various client calls to external APIs, I need to programmatically pass metadata on each message sent via either REST or SOAP clients. This metadata will be intercepted by a ClientRequestFilter to properly populate an HTTP header with the injected value.

These clients can be of different types:

• Blocking REST client calls using quarkus-rest-client
• Non-blocking REST client calls using quarkus-rest-client with either Mutiny or CompletionStage
• Blocking or non-blocking SOAP client calls using quarkus-cxf

Following your previous inputs, we implemented this requirement using ContextLocals: this approach involves storing per-client metadata in ContextLocals before performing the client call. A ClientRequestFilter then retrieves the metadata from the ContextLocals, removes it, and populates the outgoing header value accordingly.

However, this method does not apply when the bootstrap is not an inbound REST server request, such as in EDA-to-SOA applications where a Kafka-Stream processor makes a client call or in a batch application (a raw QuarkusMain app) that performs client calls. In these cases, the REST client execution is not executed from a duplicated Vert.x context, making the ContextLocals solution inapplicable.

We are considering falling back to using a ThreadLocal in such cases, based on the assumption that outside a reactive bootstrap (e.g., quarkus-rest, quarkus-reactive-messaging) that initiates the flow performing the client call, the processing is always single-threaded.

Do you have any feedback on this fallback mechanism, or do you have other suggestions for implementing this feature outside a Vert.x bootstrap? And, eventually long-term, do you foresee the possibility of enhancing the quarkus-rest-client API to provide a way to specify client metadata that could be intercepted programmatically in a ClientRequestFilter?

Thank you in advance.

[quarkus-bot[bot]]

/cc @cescoffier (rest-client), @geoand (rest-client)

[geoand]

Thanks for raising this!

ThreadLocal should be avoided at all costs as it may work sometimes, but there is no telling when it won't.
I am sure @cescoffier can comment on what to use instead of ContextLocal in your case.

[lmartella1]

Thank you both for your feedbacks. I'll wait for @ozangunalp to draw inspiration from his previous work.

In the long term, would it make sense to implement this need as a feature for the quarkus-rest-client and allow the extension to provide APIs to specify such client metadata?

[geoand]

I am not sure to be honest

[lmartella1]

To be more precise: this requirement of having arbitrary metadata bound on a given REST client call is something we already had in the past on our JBoss-based application that uses CXF. In that case, we leveraged one feature of CXF, the Request and Response context, which allows to programmatically specify client configuration or arbitrary metadata that can influence immediate message processing. That's why we believe it could be a nice feature to implement in quarkus-rest-client.

[cescoffier]

WebSocket Next is doing it too:

quarkus/extensions/websockets-next/runtime/src/main/java/io/quarkus/websockets/next/runtime/ContextSupport.java

Line 83 in 67e69e7

static Context createNewDuplicatedContext(Context context, WebSocketConnectionBase connection) {

Basically, you create a duplicated context and then do context.executeBlocking(....)
If you need to stay on the same thread, you would need something like:

quarkus/extensions/virtual-threads/runtime/src/main/java/io/quarkus/virtual/threads/ContextPreservingExecutorService.java

Line 40 in 67e69e7

public void run() {

[cescoffier]

BTW, I think CXF should dispatch on a duplicated context like almost everything in Quarkus.

[lmartella1]

Thank you @cescoffier and @geoand. We have a few use cases where the REST client call is executed outside a Vert.x context:

1. Batch Applications using QuarkusMain: For these applications, we are now successfully forcing the execution in a brand new duplicated Vert.x context by relying on the API you suggested.

2. EDA to SOA Applications using Quarkus Kafka Stream Processor: These applications execute REST client calls within the processor logic. We attempted to reuse the same approach you suggested here, but it seems to break the Kafka Stream runtime.
   Kafka Stream manages its own thread pool with some processor metadata stored in each thread. Forcing the execution on a different thread type, such as a Vert.x loop or a Vert.x worker thread, disrupts the Kafka Stream operations.
   Therefore, instead of forcing the execution on the Vert.x thread, we are creating a Vert.x context that is attached to the original Kafka-managed thread by doing the following:

    Context vertxContext = Vertx.vertx().getOrCreateContext();
    Context duplicatedContext = VertxContext.createNewDuplicatedContext(vertxContext);
    ContextInternal duplicatedContextInternal = (ContextInternal)duplicatedContext;
    duplicatedContextInternal.dispatch(event -> process(record));

We haven't identified any issues in our non-regression/unit testing with this approach. Do you have any suggestions?

[geoand]

Also cc @ozangunalp for the above

[cescoffier]

Context vertxContext = Vertx.vertx().getOrCreateContext(); is wrong - it will create a new vert.x instance every time.