A blocking operation prevents its executing thread from doing other work until the operation completes. Database, filesystem, network, and message-processing calls commonly wait on external resources. In imperative request handling, a worker thread remains occupied during that wait, increasing thread, memory, and CPU consumption as concurrency grows. section 8.1.1
Blocking is especially important in reactive applications. Quarkus uses Netty event-loop threads to interleave concurrent nonblocking I/O, so blocking those threads undermines the processing model. Quarkus logs a warning when an event loop is blocked for the configured period and may reject recognized blocking operations immediately. section 8.1.1
Handle blocking work by separating it from nonblocking execution:
- Move work that must wait onto a worker thread or another processing channel instead of running it on the event loop. section 8.1.1 section 9.8.2
- Use a dedicated in-memory channel when message processing must wait for an external action. section 9.8.2
Blocking payment simulation
A payment consumer receives invoices through the invoices-requests channel, calls a payment routine that sleeps for a random one-to-five seconds, updates the invoice, and emits an InvoiceConfirmation. The @Blocking annotation keeps this wait out of the nonblocking I/O thread. section 9.8.2
