[CASSANDRA-19166] StackOverflowError on ALTER after many previous schema changes

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 4.1.4, 5.0-beta2, 5.0
• Component/s: Cluster/Schema
• Bug Category: Degradation - Other Exception
• Severity: Normal
• Complexity: Normal
• Discovered By: User Report
• Platform: All
• Since Version: 4.1.0

Source Control Link

https://github.com/apache/cassandra/commit/a443990bfa64e239810876121f2877064f2d9ae8

Test and Documentation Plan

Existing tests should pass, no additional tests

• Assignee: Abe Ratnofsky
• Reporter: Abe Ratnofsky

Authors

Abe Ratnofsky

Reviewers

Caleb Rackliffe, Jacek Lewandowski

• Created: 05/Dec/23 04:01
• Updated: 18/Dec/23 08:58
• Resolved: 06/Dec/23 17:12

Description

Since 4.1, TableMetadataRefCache re-wraps its fields in Collections.unmodifiableMap on every local schema update. This causes TableMetadataRefCache's Map fields to reference chains of nested UnmodifiableMaps. Eventually, this leads to a StackOverflowError on get(), which has to traverse lots of these maps to fetch the actual value.

https://github.com/apache/cassandra/blob/4059faf5b948c5a285c25fb0f2e4c4288ee7c305/src/java/org/apache/cassandra/schema/TableMetadataRefCache.java#L53

The issue goes away on restart, since TableMetadataRefCache is reloaded from disk.

See CASSANDRA-17044, when TableMetadataRefCache was introduced. This issue was discovered on a real test cluster where schema changes were failing, via a heap dump.

Issue Links

• links to: GitHub Pull Request #2962