java.nio.channels.ClosedByInterruptException

Q: Designate interrupts as the official cancel button

When to use: Use this when/if shutdown should abort in-flight network waits promptly.. Embrace the contract: catching CBIE means cancellation succeeded. Return from the worker, release resources, and reopen channels only when the component itself restarts. This yields prompt, uniform teardown across sockets, files, and pipes alike.

Q: Never share interruptible channels across unrelated tasks

When to use: Use this when/if pooled or singleton connections serve mixed workloads.. Any task calling interrupt on its own thread closes the shared channel for everyone — every concurrent user receives ClosedByInterruptException or AsynchronousCloseException simultaneously. Give each cancellable unit its own channel, or protect pooled connections from foreign interrupts by scoping interrupts to owner lifecycles only.

Q: Check the flag between short operations instead

When to use: Use this when/if cancellation must not destroy expensive connections.. For long-running loops over quick reads/writes, poll Thread.currentThread().isInterrupted() at safe checkpoints and exit gracefully, keeping the channel alive for reuse. Channel-closing cancellation is reserved for truly blocking waits.

Q: Move high-fanout IO to Selectors or async channels

When to use: Use this when/if thousands of connections meet few threads.. Selector-based multiplexing handles readiness without parking a thread per connection, so interrupts stop mapping to channel closures wholesale. AsynchronousSocketChannel offers callback completion with its own cancellation handle — finer-grained than thread interruption.

Q: DEV ONLY: catch CBIE and continue using the same channel

When to use: Use this only to watch the guaranteed follow-up IOException storm — the channel is closed for good.. Subsequent operations on the closed channel throw ClosedChannelException immediately, cascading errors through every consumer. Reuse after CBIE is structurally impossible; pretending otherwise trades one loud cancellation for dozens of confusing failures.

🔴 The Error You're Seeing

Confirm this matches your console output. If it does, you're in the right place.

ERROR LOG

java.nio.channels.ClosedByInterruptException
	at java.base/java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:214)
	at java.base/sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:399)
	at com.devinhyderabad.gateway.Listener.acceptLoop(Listener.java:47)

⚡ Quick Fix Works 80% of the time

Treat CBIE as deliberate cancellation: exit cleanly, and if work continues, open a brand-new channel — the interrupted one is permanently closed.

try {
    connection = channel.accept();
} catch (ClosedByInterruptException e) {
    log.info("listener cancelled via interrupt");   // expected shutdown path
    return;
}
// continuing elsewhere? SocketChannel.open(...) fresh — never reuse this one

🧠 Why this Happens

Tap to expand the deep technical explanation

Every blocking operation on an InterruptibleChannel brackets itself with begin()/end(). While parked, an interrupt triggers two coordinated actions: the channel is closed asynchronously (so other threads blocked on it also wake) and the original operation completes by having end() detect the set interrupt status and throw ClosedByInterruptException — a subclass of AsynchronousCloseException meaning specifically this thread was interrupted. The closure is permanent; the class exists so cancellation reads as IO failure at the exact blocking line.

The HITEC City Parking Spot Analogy:

Mid-phone-call, someone pulls your phone’s battery: the conversation ends instantly, the handset is dead, and the screen’s message tells you it was switched off remotely — not that the network dropped.

🔁 How to Reproduce Confirm this is your error

Open a ServerSocketChannel bound to port 0, park a thread in accept(), interrupt it — the captured trace rises through AbstractInterruptibleChannel.end. (Lab capture: OpenJDK Temurin 25.0.2.)

🛠️ Solutions (5 Ways to Fix)

Solution 1✓ Most common cause

Designate interrupts as the official cancel button

👉 Use this when/if shutdown should abort in-flight network waits promptly.

Embrace the contract: catching CBIE means cancellation succeeded. Return from the worker, release resources, and reopen channels only when the component itself restarts. This yields prompt, uniform teardown across sockets, files, and pipes alike.

public void runListener() {
    try {
        while (true) {
            serve(channel.accept());
        }
    } catch (ClosedByInterruptException e) {
        Thread.currentThread().interrupt();  // preserve signal
        log.info("listener shut down by interrupt");
    } catch (IOException e) {
        log.error("listener io failure", e);
    }
}

Solution 2

Never share interruptible channels across unrelated tasks

👉 Use this when/if pooled or singleton connections serve mixed workloads.

Any task calling interrupt on its own thread closes the shared channel for everyone — every concurrent user receives ClosedByInterruptException or AsynchronousCloseException simultaneously. Give each cancellable unit its own channel, or protect pooled connections from foreign interrupts by scoping interrupts to owner lifecycles only.

// WRONG: shared socket channel + per-request timeouts via interrupt
// RIGHT: per-operation channel, or timeout via selector instead
try (SocketChannel ch = SocketChannel.open(addr)) {
    ch.read(buffer);   // only THIS request's interrupt can close it
}

Solution 3

Check the flag between short operations instead

👉 Use this when/if cancellation must not destroy expensive connections.

For long-running loops over quick reads/writes, poll Thread.currentThread().isInterrupted() at safe checkpoints and exit gracefully, keeping the channel alive for reuse. Channel-closing cancellation is reserved for truly blocking waits.

for (Chunk c : chunks) {
    if (Thread.currentThread().isInterrupted()) {
        throw new CancelledException();
    }
    transfer(c);       // each op is milliseconds
}

Solution 4

Move high-fanout IO to Selectors or async channels

👉 Use this when/if thousands of connections meet few threads.

Selector-based multiplexing handles readiness without parking a thread per connection, so interrupts stop mapping to channel closures wholesale. AsynchronousSocketChannel offers callback completion with its own cancellation handle — finer-grained than thread interruption.

AsynchronousSocketChannel ch = AsynchronousSocketChannel.open(group);
Future<Integer> read = ch.read(buffer);
read.cancel(true);         // cancels the read, not the whole process's channel

Solution 5

DEV ONLY: catch CBIE and continue using the same channel

👉 Use this only to watch the guaranteed follow-up IOException storm — the channel is closed for good.

Subsequent operations on the closed channel throw ClosedChannelException immediately, cascading errors through every consumer. Reuse after CBIE is structurally impossible; pretending otherwise trades one loud cancellation for dozens of confusing failures.

// ANTI-PATTERN — do not ship
catch (ClosedByInterruptException ignored) { }
ch.write(outgoing);   // ClosedChannelException, every time

📋 Version Notes

Java 8

Same begin/end protocol; FileChannel locks and transfers participate identically.

Java 11

Behavior unchanged; frame lines stable.

Java 21

Virtual threads block on NIO without pinning and interrupt cleanly; the same CBIE surfaces on the virtual thread itself.

🛡️ How to Prevent This Next Time

Document per-component ownership of channels and their cancelling interrupts, default to bounded operations plus flag-polling for cancellable-but-reusable IO, and load-test shutdown paths so interrupt-driven closures surface as designed behavior rather than surprise outages.