[ https://issues.apache.org/jira/browse/CASSANDRA-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14580538#comment-14580538 ]
Jim Witschey commented on CASSANDRA-9560: ----------------------------------------- We've reproduced the behavior [here|https://github.com/riptano/cassandra-dtest/commit/ce417ff9f74305260ca1fd75b8f4e2296a865135] and merged the test into dtest. > Changing durable_writes on a keyspace is only applied after restart of node > --------------------------------------------------------------------------- > > Key: CASSANDRA-9560 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9560 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: Single node > Reporter: Fred > Fix For: 2.1.x > > > When mutations for a column family is about to be applied, the cached > instance of the keyspace metadata is read. But the schema mutation for > durable_writes hasn't been applied to this cached instance. > I'm not too familiar with the codebase but after some debugging (2.1.3), it's > somehow related to: > {code:title=org.apache.cassandra.db.Mutation.java|borderStyle=solid} > public void apply() > { > Keyspace ks = Keyspace.open(keyspaceName); > ks.apply(this, ks.metadata.durableWrites); > } > {code} > Where a cached instance of the keyspace is opened but it's metadata hasn't > been updated with the earlier applied durable_writes mutation, since it seems > that the cached keyspace instance is lazily build at startup but after that, > never updated. I'm also a little bit concerned if other values in the cached > keyspace instance suffers from the same issue, e.g. replication_factor... > I've seen the same issue in 2.1.5 and the only way to resolve this issue is > to restart the node to let the keyspace instance cache reload from disk. -- This message was sent by Atlassian JIRA (v6.3.4#6332)