Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Message-ID: <28238495.180601292608082002.JavaMail.jira@thor>
Date: Fri, 17 Dec 2010 12:48:02 -0500 (EST)
From: "Gary Dusbabek (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Subject: [jira] Updated: (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
In-Reply-To: <17541959.93231292260801234.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gary Dusbabek updated CASSANDRA-1853:
-------------------------------------

    Attachment: v1-0001-apply-CF-metadata-updates-on-replicas.txt

> 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
>
>
> 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.