Cassandra 3.11.3 repairs SASI validation and index ownership

A secondary index participates in storage work long after its schema declaration succeeds. Cassandra 3.11.3 addresses a SASI failure in which an inappropriate analyzer and column-type combination becomes a restart problem. Another repair concerns index redistribution deleting an index file that the new view still needs. Both failures show why index correctness includes construction and file ownership as well as query evaluation.

Apache's release record dates 3.11.3 to August 1. The release changelog lists analyzer validation, the redistribution repair and removal of the B-tree builder recycler. These are distinct fixes. Their practical connection is that work intended to support normal database operation can retain the wrong resource or release one too early.

I regard Cassandra as a strong choice when the application actually needs its distributed availability model. That does not make every additional indexing option an automatic architectural choice. The mechanisms in this release are useful evidence for understanding the operational commitments attached to a particular schema.

Analyzer compatibility needs early validation

CASSANDRA-13669 reports a SASI index using StandardAnalyzer on a UUID column. The reproduction creates the table and index, inserts data and restarts Cassandra. During startup, the stack trace reaches the analyzer through the per-SSTable index writer and memtable flush machinery. The reported error is an inability to make a UUID from the analyzed value.

That sequence is more serious than a rejected query. The schema accepts a combination that later fails while Cassandra writes index data. The issue also reproduces the failure with an explicit flush. A schema declaration can therefore create deferred work whose type assumptions only become visible during storage maintenance.

The 3.11.3 changelog describes the repair as validating supported column types with the SASI analyzer. Early validation moves the failure toward the configuration that caused it. That is the appropriate place to explain that the selected analyzer cannot operate on the declared type.

A UUID's textual appearance does not establish that a language analyzer is appropriate for its storage type. The failing reproduction demonstrates that choosing an analyzer involves more than deciding whether a displayed value resembles a string. Column typing and analysis have to agree throughout index generation.

This distinction affects schema authors and operators differently. Schema authors need a rejected configuration with a useful reason. Operators need flush and startup to proceed for schemas that have already been accepted. The release note addresses validation, so it should not be interpreted as a blanket promise that every previously invalid index definition is automatically transformed into a valid one.

Redistribution has to preserve shared files

CASSANDRA-14055 describes a different SASI lifecycle error. Index redistribution creates a new view and releases old indexes. The new indexes attach to the same SSTables as the old indexes. Releasing the old objects can then delete the last SASI index file and break the index.

The subtlety is that replacement at the object level does not necessarily mean replacement of the underlying file. The old and new representations can refer to the same storage resource. A release operation that assumes exclusive ownership can remove something still required by the new view.

This explains why the changelog's wording about new SASI view creation matters. The repair concerns transition between views during redistribution. It is not an assertion that changing an index option creates a wholly independent physical index with no shared resources.

For an operator, a failure during redistribution can be difficult to reconcile with an unchanged application schema. The source issue supplies the missing relationship. The administrative process changes the objects that represent the index, and the defective release behavior changes the files underneath those objects.

I prefer this level of explanation to a general statement that indexing became more reliable. It identifies the maintenance operation involved and the resource whose ownership was wrong. That makes the fix relevant even when the application's query text has not changed.

Retained builders increase heap pressure

The B-tree work has a separate history. CASSANDRA-13929 reports retained memory associated with BTree.Builder and Netty's recycler stack after an upgrade to 3.11.0. The report distinguishes this from an earlier builder memory issue and includes heap-analysis observations.

The reporter proposes clearing a recycling handle and describes results from a patched node. Those observations belong to that report and workload. They are not a general performance measurement for the released version. The final changelog describes the release change as removing the builder recycler to reduce memory usage.

Recycling creates a lifetime that extends beyond an individual use of the object. That can save allocation when the retained objects are appropriate for reuse. It also creates a retention path that needs its own memory accounting. Here the chosen release change removes that recycling mechanism.

The distinction between the proposed workaround and the shipped change is useful. Reading only the initial issue description could lead to describing a handle-clearing patch as the release's implementation. The versioned changelog establishes that the release removes the recycler instead.

The same changelog records a reduction in nodetool garbage-collection thread count and removal of string formatting from a buffer-pool hot path. These entries do not justify a combined throughput number. They show several independent efforts to reduce incidental resource costs. For this release, the specific memory claim remains removal of the B-tree builder recycler, while the SASI changes address accepted configuration and index ownership during maintenance.