[
https://issues.apache.org/jira/browse/CASSANDRA-19166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17793582#comment-17793582
]
Jacek Lewandowski commented on CASSANDRA-19166:
-----------------------------------------------
4.1 j8
https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1149/workflows/4de1eef7-1b0a-4975-a205-c6dbb5b8f37b
> StackOverflowError on ALTER after many previous schema changes
> --------------------------------------------------------------
>
> Key: CASSANDRA-19166
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19166
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
> Reporter: Abe Ratnofsky
> Assignee: Abe Ratnofsky
> Priority: Normal
> Fix For: 4.1.x, 5.0-rc
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
