DEV Community: Jagdish Salgotra

Conditional Cancellation in Java 21: When Sibling Work Should Stop

Jagdish Salgotra — Thu, 09 Apr 2026 17:20:15 +0000

Note
This article uses Java 21 preview structured concurrency APIs (JEP 453). See Part 9 for migration changes in Java 25 preview APIs. Compile and run with --enable-preview.

Originally published on engnotes.dev:
Conditional Cancellation in Java 21

This is a shortened version with the same core code and takeaways.

Timeouts are only one kind of failure.

A lot of expensive failures happen when the outcome is already decided, but parts of the request are still doing work anyway. Payment failed. Risk check failed. Circuit breaker is already open. In those cases, letting sibling tasks continue is usually just wasted load.

That is where conditional cancellation becomes useful.

The Fail-Fast Version

One practical Java 21 pattern is to turn a terminal business failure into an exception inside the subtask, so ShutdownOnFailure can cancel sibling work:

public String circuitBreakerExample() throws Exception {
    if (circuitBreakerFailures.get() > 3) {
        logger.warn("Circuit breaker is OPEN - failing fast");
        return "Circuit breaker is OPEN - service unavailable";
    }

    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        var primaryService = scope.fork(() -> {
            if (Math.random() < 0.3) {
                circuitBreakerFailures.incrementAndGet();
                throw new RuntimeException("Service failure");
            }
            circuitBreakerFailures.set(0);
            return simulateServiceCall("primary-service", 100);
        });

        scope.join();
        scope.throwIfFailed();

        return "Circuit Breaker Result: " + primaryService.get();
    }
}

What I like here is that the fail-fast rule is not buried somewhere else in the request flow. It is part of the scope behavior.

Circuit Breaker Policy Is Still Separate

The article makes an important distinction I would keep:

public String callProtectedService(String request) throws Exception {
    if (dbCircuitBreaker.isOpen()) {
        String message = String.format(
            "Circuit breaker is OPEN for %s - failing fast (failures: %d/%d, next retry in: %s)",
            dbCircuitBreaker.getServiceName(),
            dbCircuitBreaker.getFailureCount(),
            dbCircuitBreaker.getThreshold(),
            dbCircuitBreaker.getTimeUntilRetry());
        logger.warn(message);
        throw new RuntimeException(message);
    }

    try {
        String result = scopedHandler.runInScope(() -> callUnreliableService(request));
        dbCircuitBreaker.onSuccess();
        return result;
    } catch (Exception e) {
        dbCircuitBreaker.onFailure();
        throw e;
    }
}

That separation is worth keeping straight.

the circuit breaker decides whether a call should even be attempted
the structured scope manages lifecycle for work that actually starts

Mix those up too much and the code gets harder to reason about.

Fallback Should Be Intentional

Fallback is useful too, but only when degraded results are genuinely acceptable:

public <T> T runWithFallback(Callable<T> primary, Callable<T> fallback) throws Exception {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        var primaryFuture = scope.fork(primary);

        scope.join();

        try {
            scope.throwIfFailed();
            return primaryFuture.get();
        } catch (Exception e) {
            logger.warn("Primary task failed, using fallback: {}", e.getMessage());
            return fallback.call();
        }
    }
}

I would not use this as a default escape hatch for every failure. It makes sense for optional enrichments. It is a bad habit when it starts hiding broken primary paths.

The Java 21 Review Rule

For this style of code, I would still review the same basics first:

convert terminal business failures into explicit exceptions if they should stop sibling work
call join() before reading results
call throwIfFailed() before get
keep retries bounded and visible
keep side effects idempotent where cancellation can happen mid-flow

Those are the details that make fail-fast code trustworthy instead of just clever.

The Practical Takeaway

What structured concurrency gives you here is a cleaner boundary for business-condition failure.

If the request is already done in business terms, the code should be able to say that clearly and stop the rest. That is a better model than letting work leak on just because the tasks were launched.

Full article with more examples, testing guidance, runnable repo, and live NoteSensei chat:

Conditional Cancellation in Java 21

Timeout Patterns in Java 21: Full Failure vs Partial Results

Jagdish Salgotra — Mon, 06 Apr 2026 17:10:28 +0000

Note
This article uses the Java 21 preview structured concurrency API (StructuredTaskScope, JEP 453). API shape changed in later previews. See Part 9 for Java 21 -> Java 25 migration guidance. Compile and run with --enable-preview.

Originally published on engnotes.dev:
Timeout Patterns in Java 21

This is a shortened version with the same core code and takeaways.

Timeout handling gets oversimplified pretty often.

The real design question is usually not “did we hit the deadline?” It is “what should the response mean once we do?” Some endpoints should fail completely. Others should return what is ready and mark the rest as missing. Structured concurrency helps, but it does not make that decision for you.

The Strict Version

This is the simple all-or-nothing pattern from the article:

public <T> T runInScopeWithTimeout(Callable<T> task, Duration timeout) throws Exception {
    Instant deadline = Instant.now().plus(timeout);

    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        var future = scope.fork(task);
        scope.join();

        if (Instant.now().isAfter(deadline)) {
            throw new TimeoutException("Operation exceeded timeout: " + timeout);
        }

        scope.throwIfFailed();
        return future.get();
    }
}

This is usually the right choice when the whole response has to be correct or not returned at all.

The Partial-Results Version

When some sections are optional, the response policy changes:

public <T> List<Optional<T>> executeWithPartialResults(List<Callable<T>> tasks, Duration timeout)
        throws InterruptedException {
    Instant deadline = Instant.now().plus(timeout);

    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        List<StructuredTaskScope.Subtask<T>> subtasks = new ArrayList<>();
        for (Callable<T> task : tasks) {
            subtasks.add(scope.fork(task));
        }

        try {
            scope.joinUntil(deadline);
        } catch (TimeoutException ignored) {
            // Deadline reached: return what is available.
        }

        List<Optional<T>> results = new ArrayList<>(subtasks.size());
        for (var subtask : subtasks) {
            if (subtask.state() == StructuredTaskScope.Subtask.State.SUCCESS) {
                results.add(Optional.of(subtask.get()));
            } else {
                results.add(Optional.empty());
            }
        }

        scope.shutdown();
        return results;
    }
}

That is the part I like here. The timeout policy is explicit. You can tell from the code whether the endpoint is strict or whether it is allowed to degrade.

The Important Java 21 Caveat

joinUntil(...) only tells you the deadline was reached. It does not decide your response policy for you.

That means you still need to answer a few questions yourself:

should the endpoint fail completely?
should it return partial data?
how should missing sections be represented?
should unfinished work be cancelled right away?

That last point matters more than people think. In the Java 21 preview style, if you return early with partial data, remember scope.shutdown(). Forgetting that is a good way to leave stale work running after the response is already gone.

When To Choose Which

I would use full failure when:

the response only makes sense if all parts are present
downstream decisions depend on complete data
partial data would be misleading

I would consider partial results when:

some fields are optional or just enrichments
degraded output is acceptable
the response contract clearly marks what is missing

That decision is usually more important than the concurrency primitive itself.

The Practical Takeaway

What structured concurrency gives you here is not “automatic timeout design.” It gives you a cleaner place to express timeout design.

That is useful because the code stops hiding the response policy. You can see whether the endpoint is strict, whether it degrades, and whether unfinished work gets cleaned up properly.

Full article with more examples, progressive callbacks, test guidance, runnable repo, and live NoteSensei chat:

Timeout Patterns in Java 21

Structured Concurrency in Java 21: What It Fixes and Why It Exists

Jagdish Salgotra — Thu, 26 Mar 2026 05:30:26 +0000

Note
This series uses the Java 21 preview API for structured concurrency (StructuredTaskScope, JEP 453). The API evolved in later previews. See Part 9 for Java 21 -> Java 25 migration guidance. Compile and run with --enable-preview.

Originally published on engnotes.dev:

Introduction to Structured Concurrency in Java 21

This is a shortened version with the same core code and takeaways.

The annoying part of concurrent request code is usually not starting work in parallel. Java has had plenty of ways to do that for years.

The real mess shows up later. One task fails. Another keeps running. Cancellation is inconsistent. Cleanup is half in one method and half somewhere else. That is the problem structured concurrency is trying to fix.

The Old Shape

This is a very normal baseline from the project:

CompletableFuture<String> cf1 = CompletableFuture.supplyAsync(() -> simulateService("Service-A", 200));
CompletableFuture<String> cf2 = CompletableFuture.supplyAsync(() -> simulateService("Service-B", 300));
CompletableFuture<String> cf3 = CompletableFuture.supplyAsync(() -> simulateService("Service-C", 100));

CompletableFuture.allOf(cf1, cf2, cf3).join();

String result = String.format("Results: %s, %s, %s",
    cf1.get(), cf2.get(), cf3.get());

This works. The problem is that failure policy and lifecycle are not obvious from the structure of the code. Once timeouts, cancellation, and cleanup matter, that usually spreads out across multiple call sites.

The Java 21 Preview Model

Structured concurrency gives the related work one explicit scope owner:

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var task1 = scope.fork(() -> simulateService("Service-A", 200));
    var task2 = scope.fork(() -> simulateService("Service-B", 300));
    var task3 = scope.fork(() -> simulateService("Service-C", 100));

    scope.join();
    scope.throwIfFailed();

    String result = String.format("Results: %s, %s, %s",
        task1.get(), task2.get(), task3.get());
    logger.info(result);
}

That is the real shift.

The tasks live in one scope. The failure policy is visible. Cleanup happens with scope exit. It reads much closer to the actual lifecycle of the request.

The Java 21 Review Rule

In the Java 21 preview API, the safe baseline is simple:

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var future = scope.fork(task);
    scope.join();
    scope.throwIfFailed();
    return future.get();
}

If I were reviewing this code, that is the sequence I would look for first:

fork the related work inside one scope
join before reading results
throwIfFailed before get

Miss that middle step, or skip throwIfFailed, and the code gets harder to trust.

Where It Fits Well

Structured concurrency is a good fit for:

I/O-heavy fan-out request paths
service aggregation with one clear failure policy
code that needs reliable cancellation and cleanup

It is less interesting for:

pure CPU-heavy batch work
long-lived background processing
teams that cannot use preview APIs in production yet

It also pairs naturally with virtual threads. Virtual threads keep blocking code direct. Structured scopes keep the lifecycle visible.

The Practical Takeaway

What I like about structured concurrency is that it makes concurrent work look like one operation again instead of a loose collection of tasks.

That sounds small, but it changes how readable the code is and how predictable failure handling becomes.

Full article with more examples, Java 21 preview setup details, runnable repo, and live NoteSensei chat:

Introduction to Structured Concurrency in Java 21

Java Virtual Threads in 2025: Scalable I/O Without Async Hell (and the Real Limits)

Jagdish Salgotra — Sat, 21 Mar 2026 19:19:47 +0000

Note This article uses Java 21 as the baseline. Virtual threads are stable in Java 21 (JEP 444), so no preview flags are needed here.

Originally published on engnotes.dev: https://engnotes.dev/blog/project-loom/virtual-threads-revolution-part-1
This is a shortened version with the same core code and takeaways.

If you have worked on Java backends long enough, you have probably seen the same problem show up again and again. The business logic is not especially hard. The traffic is. Then the thread math starts. How many threads, how much memory, how much waiting, how much tuning before the whole thing starts feeling awkward.

That is the pain virtual threads address.

The Old Problem

Platform threads are expensive. Each one uses real OS resources and carries a meaningful memory cost. For blocking I/O workloads, that puts a ceiling on concurrency much earlier than most teams want.

This is the usual shape:

public class PlatformThreadPoolServer {
    private static final int PORT = 8080;
    private static final int THREAD_POOL_SIZE = 20;
    private static final long BLOCKING_SIMULATION_TIME = 200;

    public static void main(String[] args) throws IOException {
        ExecutorService threadPoolExecutor = Executors.newFixedThreadPool(THREAD_POOL_SIZE);
        HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);

        server.createContext("/api", exchange -> {
            threadPoolExecutor.submit(() -> {
                try {
                    Thread.sleep(BLOCKING_SIMULATION_TIME);
                    String response = "Platform Thread Ok\n";
                    exchange.sendResponseHeaders(200, response.length());
                    exchange.getResponseBody().write(response.getBytes());
                    exchange.close();
                } catch (Exception e) {
                    e.printStackTrace();
                }
            });
        });

        server.setExecutor(null);
        server.start();
    }
}

This works, until too many requests block at once. Then threads stay tied up, queues grow, and latency starts getting ugly.

Most of us worked around that with bigger pools, more tuning, or async/reactive code. Sometimes that was the right call. A lot of the time it was just the cost of an old model.

What Virtual Threads Change

The big change is not new syntax. The code still looks like normal Java.

public class VirtualThreadPoolServer {
    private static final int PORT = 8080;
    private static final long BLOCKING_SIMULATION_TIME = 200;

    public static void main(String[] args) throws IOException {
        ExecutorService loomExecutor = Executors.newVirtualThreadPerTaskExecutor();
        HttpServer server = HttpServer.create(new InetSocketAddress(8080), 0);
        server.createContext("/api", exchange -> {
            loomExecutor.submit(() -> {
                try {
                    Thread.sleep(BLOCKING_SIMULATION_TIME);
                    String response = "Virtual Thread Ok\n";
                    exchange.sendResponseHeaders(200, response.length());
                    exchange.getResponseBody().write(response.getBytes());
                    exchange.close();
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt();
                } catch (Exception e) {
                    e.printStackTrace();
                }
            });
        });

        server.setExecutor(null);
        server.start();
    }
}

That is why Loom feels so practical. The control flow stays direct. The code stays readable. But the runtime behavior changes in a way that matters a lot for I/O-heavy systems.

The Useful Mental Model

Virtual threads use M:N scheduling. Many virtual threads run on a smaller set of carrier threads, which are regular platform threads.

The important bit is this:

when a virtual thread blocks on I/O, it parks and releases its carrier thread. That carrier thread can immediately run something else.

That is the part that changes the tradeoff. Blocking no longer means burning an OS thread while you wait.

Where They Help

Virtual threads are a strong fit for:

web services handling lots of concurrent requests
database calls, file operations, and network I/O
task-oriented backend flows where blocking is the natural model
systems where async complexity has grown faster than the business logic

Where They Do Not Magically Help

Virtual threads improve request concurrency. They do not remove system limits.

database pools still cap throughput
external APIs still rate limit you
socket and file descriptor limits still matter
CPU-bound work usually does not get the same benefit
pinning can still hurt if you keep blocking work inside synchronized hot paths or long native calls

That part is worth being honest about. Loom fixes one painful layer of the problem. It does not make bottlenecks disappear.

Key Takeaway

What I like about virtual threads is that they make Java feel a bit less like it is fighting the shape of backend work. For a lot of I/O-heavy services, the straightforward blocking model becomes practical again.

It is just a much better default than what we had before.

Full article with all diagrams, larger code examples, runnable repo, and live NoteSensei chat (ask me anything about virtual threads), check understanding by playing quiz:

https://engnotes.dev/blog/project-loom/virtual-threads-revolution-part-1