Cassandra 4.0.15 isolates connection authentication work

A reconnect flood can compete with the traffic from clients that are already connected. In Cassandra, bcrypt verification makes authentication a meaningful unit of CPU work. Version 4.0.15 backports a mechanism that separates that work from general request handling, so a burst of authentication requests has a bounded place to wait without consuming the same execution capacity as everything else.

The release record dates 4.0.15 to November 18. Its tagged changelog identifies the authentication backport, configurable batchlog endpoint strategies, and snapshot schema corrections. These changes concern how the database behaves under operational pressure and how it preserves the information needed for recovery.

I am interested in Cassandra where active-active operation at scale is required. In that setting, failure isolation includes protecting useful ongoing work from expensive connection setup. A node can be reachable and still spend its execution capacity on the wrong class of request.

Authentication gets its own execution capacity

The original authentication issue describes a flood of reconnects overwhelming bcrypt validation. It identifies bad client behavior or configuration as one possible trigger. The problem does not require assuming that normal steady traffic is malicious. A client repeatedly trying to recover can create expensive work at a particularly inconvenient time.

The documented mechanism moves authentication requests into a small separate executor pool. If that pool backs up, authentication can time out while the rest of request handling continues making progress. The 4.0 backport brings that isolation into this maintenance release.

This differs from limiting the total number of connections. A total connection cap can stop clients establishing connections at all, but it does not express the same separation between setup work and established request traffic. The issue explicitly describes that cap as an imperfect existing option.

The separate pool does not make password verification free. It controls where contention occurs. A caller trying to authenticate can experience delay or failure while established operations retain their own capacity. That is a deliberate tradeoff about which work should remain able to progress during a reconnect burst.

Client behavior still matters after a timeout. The issue expects clients to back off and retry, rather than treating every failed attempt as a reason to issue another immediately. Executor isolation protects the server's other work, while backoff reduces the rate at which the client replenishes the overloaded queue.

I consider that distinction useful because it avoids treating availability as one undifferentiated property. New authentication can be constrained while ordinary requests remain serviceable. The operational outcome is more precise than either allowing every setup attempt to compete freely or refusing all new clients at a connection-count boundary.

Batchlog selection can account for different priorities

The release adds batchlog endpoint strategies named random_remote, prefer_local, dynamic_remote, and dynamic. The motivating issue describes a very slow node that remained alive in gossip and reduced throughput for logged batch writes. Selecting a live endpoint did not establish that it could acknowledge batchlog work promptly.

The report explains that logged batches wait for their batchlog writes before proceeding with the actual mutations. Randomly selecting an endpoint that is reachable but severely slow can therefore affect work coordinated elsewhere. The database's ordinary write consistency choice does not remove that earlier dependency in the reported path.

The issue's throughput figures belong to its own environment and reproduction, so they should not become a promised performance change for every deployment. The shipped addition is a set of configurable selection strategies. It gives endpoint choice a policy beyond assuming that every live node is equally suitable for that work.

This is related to authentication isolation in its operational purpose, but the mechanisms differ. One reserves execution capacity for a class of work. The other changes how the system can choose nodes for a prerequisite operation. Both address cases where a narrow source of slowness can delay otherwise useful traffic.

Snapshot schema must include hidden dependencies

CASSANDRA-20036 identifies missing user-defined types in the schema statements generated with a snapshot. A UDT used in a descending clustering column sits inside a reversed type representation. Looking only for the outer type can miss the UDT that must be created before the table can be reconstructed.

The issue also identifies ordering among dependent UDTs. If one type refers to another, generating their creation statements in arbitrary hash order is insufficient. The referenced type has to exist before the dependent definition can be applied.

These are recovery metadata problems, rather than evidence that the live table cannot store its existing values. A snapshot can contain data while the accompanying recreation statements omit a prerequisite. The release repairs that schema description so the metadata better represents what reconstruction requires.

For me, that makes 4.0.15 a useful maintenance release beyond its authentication headline. It limits one form of request starvation, adds explicit choices for batchlog placement, and corrects dependencies in generated recovery schema. Each change puts responsibility at the point where Cassandra can preserve progress or supply the information a later operation needs.