cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Patterson (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-3821) Counters in super columns don't preserve correct values after cluster restart
Date Tue, 21 Feb 2012 19:03:46 GMT

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

Tyler Patterson updated CASSANDRA-3821:
---------------------------------------

    Description: 
Set up a 3-node cluster with rf=3. Create a counter super column family and increment a bunch
of subcolumns 100 times each, with cf=QUORUM. Then wait a few second, restart the cluster,
and read the values back. They almost all come back different (and higher) then they are supposed
to be.

Here are some extra things I've noticed:
 - Reading back the values before the restart always produces correct results.
 - Doing a nodetool flush before killing the cluster greatly improves the results, though
sometimes a value will still be incorrect. You might have to run the test several times to
see an incorrect value after a flush.
 - This problem doesn't happen on C* 1.0.7, unless you don't sleep between doing the increments
and killing the cluster. Then it sometimes happens to a lesser degree.

A dtest has been added to demonstrate this issue. It is called "super_counter_test.py".

  was:
Set up a 3-node cluster with rf=3. Create a counter super column family and increment a bunch
of subcolumns 100 times each, with cf=QUORUM. Then wait a few second, restart the cluster,
and read the values back. They almost all come back different (and higher) then they are supposed
to be.

Here are some extra things I've noticed:
 - Reading back the values before the restart always produces correct results.
 - Doing a nodetool flush before killing the cluster greatly improves the results, though
sometimes a value will still be incorrect. You might have to run the test several times to
see an incorrect value after a flush.
 - This problem doesn't happen on C* 1.0.7, unless you don't sleep between doing the increments
and killing the cluster. Then it sometimes happens to a lesser degree.

The dtest that demonstrates this issue is called "super_counter_test.py". Run it like this:
nosetests --nocapture super_counter_test.py  You'll need ccm from git@github.com:tpatterson/ccm.git.

    
> Counters in super columns don't preserve correct values after cluster restart
> -----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-3821
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-3821
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.1.0
>         Environment: ubuntu, 'trunk' branch, used ccm to create a 3 node cluster with
rf=3. A dtest was created to demonstrate.
>            Reporter: Tyler Patterson
>            Assignee: Sylvain Lebresne
>             Fix For: 1.1.0
>
>
> Set up a 3-node cluster with rf=3. Create a counter super column family and increment
a bunch of subcolumns 100 times each, with cf=QUORUM. Then wait a few second, restart the
cluster, and read the values back. They almost all come back different (and higher) then they
are supposed to be.
> Here are some extra things I've noticed:
>  - Reading back the values before the restart always produces correct results.
>  - Doing a nodetool flush before killing the cluster greatly improves the results, though
sometimes a value will still be incorrect. You might have to run the test several times to
see an incorrect value after a flush.
>  - This problem doesn't happen on C* 1.0.7, unless you don't sleep between doing the
increments and killing the cluster. Then it sometimes happens to a lesser degree.
> A dtest has been added to demonstrate this issue. It is called "super_counter_test.py".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message