cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1853) changing row cache save interval is reflected in 'describe keyspace' on node it was submitted to, but not nodes it was propagated to
Date Tue, 21 Dec 2010 14:38:01 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973676#action_12973676
] 

Jonathan Ellis commented on CASSANDRA-1853:
-------------------------------------------

bq. I'm talking about this one

... that's in the _avro_ CassandraServer, btw.

> 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
>          Components: Core
>            Reporter: Peter Schuller
>            Assignee: Gary Dusbabek
>            Priority: Minor
>             Fix For: 0.7.0
>
>         Attachments: v1-0001-apply-CF-metadata-updates-on-replicas.txt, v2-0001-apply-CF-metadata-updates-only-at-apply-time.txt,
v3-0001-apply-CF-metadata-updates-only-at-apply-time.txt
>
>
> 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.


Mime
View raw message