[
https://issues.apache.org/jira/browse/CASSANDRA-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12970909#action_12970909
]
Peter Schuller commented on CASSANDRA-1853:
-------------------------------------------
Forgot to say that restarting the nodes in question (that do not show the
updated value) causes it to catch up in describe keyspace output.
> changing row cache save interval is reflected in 'describe keyspace' on node
> it was submitted to, but not nodes it was propagated to
> ------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-1853
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1853
> Project: Cassandra
> Issue Type: Bug
> Reporter: Peter Schuller
> Priority: Minor
>
> This is minor unless it indicates a bigger issue. On our test cluster
> (running cassandra 0.7 branch from today) we noticed that on submission of a
> new row cache save period, such as:
> update column family KeyValue with row_cache_save_period=3600;
> The change would be reflected in describe_keyspace() (describe keyspace ...
> in cassandra-cli) on the node to which the schema migration was submitted,
> but not on other nodes in the cluster.
> This in spite of the schema migration having propagated, judging by
> Schema['Last Migration'] being identical on all nodes. It is not n and of
> itself is not a big problem, but it does give the impression that the
> migrations have trouble propagating throughout the cluster even though they
> do.
> (I had a quick (only) look in the code paths of migration application and did
> not find any obvious special casing of the node that happens to be local.
> Filing bug instead, hoping someone knows off hand what the reason is.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
