pause

Pauses the container backing dc via the Docker API (docker pause), simulating "this datacenter is unreachable" for failover tests without tearing down and losing the ability to bring it back.

What this actually simulates -- and what it doesn't (GH #108 / ISS-095)

Docker pause freezes the container's userspace processes via the Linux cgroup freezer. It does not sever the container's network namespace or stop the host kernel's TCP stack for it -- any TCP connection already established to this node stays alive at the socket level, simply going quiet because nothing on the far end is scheduled to read or write it anymore. That's closer to "the Cassandra process hung" than "the network link went down": a real network partition (a severed link, a firewall rule, an unplugged cable) typically produces immediate TCP RSTs or ICMP host/port-unreachable on new connection attempts, and can also kill already-established connections outright -- neither of which pause produces. No RST, no ICMP unreachable, and existing sockets are never actively torn down by this call.

The tests in io.kandra.multidc.MultiDcFailoverTest that use this are built around bounded retry loops tolerant of either failure mode (both eventually manifest as the driver giving up on the node), so this distinction hasn't been observed to change their outcome -- but don't read a passing failover test here as proof of behavior under a severed link, only under an unresponsive/hung node. Always pair with unpause (or unpauseAll) in @AfterEach -- a paused container left paused breaks every later test sharing this JVM-wide topology.

If the JVM dies between pause and cleanup

@AfterEach/try-finally cleanup only runs if the JVM is alive to run it. If the JVM itself dies mid-test (a crash, an OOM, System.exit, a killed build daemon) after pause but before unpause/unpauseAll runs, dc1/dc2 is left frozen with nothing left in this process to unpause it. The actual backstop in that scenario is Testcontainers' own Ryuk resource-reaper sidecar, which force-removes every container/network this JVM started once it detects the JVM is gone -- a removed container rather than an indefinitely frozen one, but not an immediate/synchronous guarantee. This reliance is implicit rather than something the fixture enforces itself; there is no JVM-shutdown-hook-based unpause here.