CODEWITHSUNDEEP
javamultithreadingquarkusmutiny
drobert
drobert

Reputation: 1310

quarkus reactive mutiny thread pool management

Background: I'm just this week getting started with Quarkus, though I've worked with some streaming platforms before (especially http4s/fs2 in scala).

Working with quarkus reactive (with mutiny) and any reactive database client (mutiny reactive postgres, reactive elasticsearch, etc.) I'm a little confused how to correctly manage blocking calls and thread pools.

The quarkus documentation suggests imperative code or cpu-intensive code to annotated with @Blocking to ensure it is shifted to a worker pool to not block the IO pool. This makes sense.

Consider the following:

public class Stuff {
  // imperative, cpu intensive
  public static int cpuIntensive(String arg) { /* ... */ }

  // blocking IO
  public static List<Integer> fetchFromDb() { /* ... */ }

  // reactive IO
  public static Multi<String> fetchReactive() { /* ... */ }

  // reactive IO with CPU processing
  public static Multi<String> fetchReactiveCpuIntensive(String arg) {
    fetchReactive() // reactive fetch
      .map(fetched -> cpuIntensive(arg + fetched)) // cpu intensive work
  }
}

It's not clear to me what happens in each of the above conditions and where they get executed if they were called from a resteasy-reactive rest endpoint without the @Blocking annotation.

Presumably it's safe to use any reactive client in a reactive rest endpoint without @Blocking. But does wrapping a blocking call in Uni accomplish as much for 'unsafe' clode? That is, will anything returning a Multi/Uni effectively run in the worker pool?

(I'll open follow-up posts about finer control of thread pools as I don't see any way to 'shift' reactive IO calls to a separate pool than cpu-intensive work, which would be optimal.)

Edit

This question might imply I'm asking about return types (Uni/Multi vs direct objects) but it's really about the ability to select the thread pool in use at any given time. this mutiny page on imperative-to-reactive somewhat answers my question actually, along with the mutiny infrastructure docs which state that "the default executor is already configured to use the Quarkus worker thread pool.", and the mutiny thread control docs handles the rest I think.

So my understanding is this:

If I have an endpoint which conditionally can return something non-blocking (e.g. a local non-blocking cache hit) then I can effectively return any way I want on the IO thread. But if said cache is a miss, I could either call a reactive client directly or use mutiny to run a blocking action on the quarkus worker pool. Similarly mutiny provides control to execute any given stream on a specific thread pool (executor).

And reactive clients (or anything effectively running on the non-IO pool) is safe to call because the IO loop is just subscribing to data emitted by the worker pool.

Lastly, it seems like I could configure a cpu-bound pool separately from an IO-bound worker pool and explicitly provide them as executors to whichever emitters I need. So ... I think I'm all set now.

Upvotes: 2

Views: 2492

Answers (1)

geoand
geoand

Reputation: 64011

This is very good question!

The return type of a RESTEasy Reactice endpoint does not have any effect on which thread the endpoint will be served on. The only thing that determines the thread is the presense of @Blocking / @NonBlocking.

The reason for this is simple: By just using the return type, it is not possible to know if the operation actually takes a long time to finish (and thus block the thread). A non-reactive return type for example does not imply that the operation is CPU intensive (as you could for example just be returning some canned JSON response). A reactive type on the other hand provides no guarantee that the operation is non-blocking, because as you mention, a user could simply wrap a blocking operation with a reactive return type.

Upvotes: 2

Related Questions