Thread pool thread

As explained in Quarkus in Action

A worker thread is a thread assigned blocking or computational work outside an event loop.

A thread pool thread is a worker thread assigned to handle a request, including its blocking or computational work. In imperative execution, each incoming request receives a thread from a predefined pool and keeps it until completion. section 8.1.1

Blocking I/O makes the worker thread wait while a database, filesystem, network service, or message broker responds. During that wait, the thread performs no other work, consuming memory and CPU capacity as concurrency grows. section 8.1.1 section 7.7

Reactive Quarkus applications reserve event-loop threads for nonblocking work and move blocking operations to worker threads. After the blocking operation finishes, execution can return to the event loop. section 8.1.1 section 7.7

Quarkus selects the execution thread using the endpoint’s behavior:

• Return a Uni to run the method on the nonblocking I/O thread; do not block that thread. section 8.4.1
• Use @Blocking to run a method on a worker or executor thread when its work may block. section 8.4.1
• Use @NonBlocking to select nonblocking execution for a method that does not return Mutiny types. section 8.4.1

Blocking persistence

Traditional Hibernate ORM performs blocking database access, so Quarkus delegates that operation to a worker thread rather than blocking the event loop. Hibernate Reactive and reactive database drivers generally avoid that delegation through reactive APIs. section 7.7

Figure 8.1 Blocking I/O request handling: threads are blocked while waiting for an I/O operation to complete

Compare request handling that holds worker threads during I/O with event-driven handling that keeps a small set of event-loop threads available. section 8.1.1

How Quarkus in Action covers it

How deep it goes

Explains request assignment, blocking costs, thread selection, and delegation, but does not detail pool sizing or scheduling internals.

Examples

Uses request I/O, traditional Hibernate ORM, reactive database drivers, Uni endpoints, and @Blocking or @NonBlocking annotations.

What it assumes

Assumes basic request handling and database access while teaching the distinction between imperative workers and reactive event-loop threads.

What you can do after

Diagnose event-loop blocking and route blocking endpoint work with @Blocking or reactive persistence APIs.

How it connects

Connects worker threads with event loops, nonblocking I/O, Mutiny, Quarkus, Vert.x, Netty, and reactive database access.

liveBookmanning.com

Read Quarkus in Action on liveBook Get the book at manning.com

Related concepts

• Task.Runused by · Task.Run is a .NET method that schedules synchronous or asynchronous work on a thread-pool thread and returns a Task representing it.
• thread poolpart of · A worker pool is a managed collection of workers that execute submitted or queued tasks, typically reusing workers to handle multiple tasks concurrently.
• @Blockingconfigured by · @Blocking is an annotation that marks an operation as potentially blocking so a reactive framework can schedule it on a worker thread.
• blockingused by · Execution behavior in which an operation prevents its calling execution flow from progressing until required work, an event, a resource, or a condition is ready or complete.
• threadkind of · A thread is an independently schedulable sequence or context of execution within a program or process.
• event loop threadused by · An event loop thread is a thread that runs an event loop to process asynchronous application events and callbacks.

This explainer was generated by Manning's knowledge graph from the text of Quarkus in Action. The section links point to the parts of the book it draws on.